Fairly recently I've been trying to make my own web based android app and have been going crazy trying to find a working drag to scroll JavaScript but surprise, surprise, turns out I didn't need it. Because as long as the overflow parameters are not set to hidden, I could drag-scroll like crazy.
I'm very new to this web to app thing so can anyone explain why and how this works? Because I can't seem to find the right key words to find a documentation for it.
This is because of a change on Android in the WebKit browser that was started in this issue:
https://bugs.webkit.org/show_bug.cgi?id=78664
The property was added in this revision.
Looking at the code you can see it's default value is touch on touch-enabled devices.
Related
Based on my experience and research, the out-of-the-box AV players for both Android and iOS do not fully support gapless/seamless looping. There is always a noticable gap when setting the isLooping=true on any of them. I have only been able to get this to seamlessly work on Android using the SoundPool, but that is only for small sound files, not large mp3's.
Currently, i wrote a solution that "semi-works" for iOS, but the weird thing is that it does not work on Android. I would guess they should at least be consistent?
Also, I'm interested if anyone could help solve this age-old problem of looping sounds in the most effective way possible where the user does not notice a gap. This cross fader idea is out of the box and maybe someone can help improve on it. I also opened a discussion on the expo forum and will update here if anything comes from there.
Here is the repo: https://github.com/happyruss/expo-fader-loop
Any suggestions on solving the issue would be awesome. It's also a fun simple project for someone trying out react-native/expo
I ran into a bug that seems very nuanced and strange. I am using OpenLayers (v4.0.1) in a web application to display multiple WMS layers from a GeoServer (v2.8.2). Everything seemed to be working great until Windows 10 did a big update. Shortly thereafter, my browser began to crash when attempting to view the page on which the map and all of its layers should be displayed.
After a lot of digging, it appeared that this issue only shows up in Chrome Version 60 (60.0.3112.90 to be exact). I tried to reproduce the issue on multiple OS's and browser combinations (Linux/Windows/Mac and Firefox/IE/Edge/Chrome Version 59) and it works great everywhere except on Chrome 60 (across all OS's).
Though still hard to pin-point exactly, when doing a step-through of the JavaScript to find where the hang-up occurs, it is definitely happening somewhere inside of the OpenLayers code. Another key discovery is that the error does not occur at all if the browser window size is "small" enough. In other words, if I resize my window and try again, it will suddenly work consistently once a somewhat-random-seeming, certain browser size is reached. It seems to be more area-dependent, though, than a specific height/width constraint, as various height/width combinations will either work or not work.
At this point I have no great idea on how to resolve this issue, so I'm starting here by simply wondering if anyone knows if it would make sense that something in Chrome 60 is changing the behavior of the OpenLayers JavaScript library? If so, I'd want to open up an official GitHub issue with them. If not, would it be a Chrome issue I'd report? I'm reluctant to believe it is something that I have programmed, as it works in every other browser.
Thoughts?
This does indeed sound like a Chrome bug. Please file a bug at crbug.com/new, and include:
repro instructions (ideally, a link to a site that will trigger the crash)
any crash reports you see in chrome://crashes (if this is what caused them)
If you post the bug number here, I'll make sure it gets looked at. Thanks!
been a few weeks trying different ways to detect a cross-domain iframe click on mobile without success.
I have tried all that has come through, all plugins, all forum tips, and yet i can't get a way to do it.
I coded whatever way i through will work and i got no positive results.
Some plugins are working on newest phones like s6/7 (maybe for other older phones too?) using blur events but i need a reliable solution that will work with most to date phones.
Maybe there is a workaround with touchstart function for mobile..
I lost my chances into believing that there's a way to do it so today i am asking here maybe someone figured it out.
Thank you.
Ps this is a demo of a plugin called iframetracker.
Can someone tell me if it works on old mobiles? http://cdn.rawgit.com/vincepare/iframeTracker-jquery/master/demo/index.html
The answer in short is No.
Regarding your plugin, on the github, it states very clearly:
About mobile devices
This plugin doesn't work on mobile devices such as smartphones and tablets, because this hardware uses a touchscreen instead of a mouse as click input. This design makes the boundary monitoring trick useless
This is why you won't find a solution for your issue.
There is no known work around for your particular problem with touch screen devices.
I've been tasked with creating a website (using mainly javascript & JQuery) that reads in a certain element from a website - e.g. the navigation bar - and test it to see how it react at different screen sizes.
My question is that is this a good approach? To test elements one at a time instead of just testing the responsiveness of the whole page? Wouldn't an element react differently to media query changes with other elements around it, rather than the element by itself?
My vote will be to firefox default responsive tester. Use Ctrl+Shift+M to make the firefox screen responsive.
If you want to see the dimensions with name, go with google chrome, right-click, inspect element. There you will see a mobile icon. Click that.This will give you a dropdown of variety of devices.
Usually the good approach is to test the whole page. But clearly there are cases when element testing is necessary, even disabling certain ones and check the rest together. So the tool you're about to create actually makes sense; not good enough, tho. But maybe you're better off with a Google Chrome element inspector and some "display:none"-s.
(Side note: this is my own responsivity tester and I never needed much more than this. It aims for the typical bootstrap breakpoints; it has maybe twelve lines of code, it's just as complex as a screwdriver.)
If you want to try it on native devices you should check out www.browserstack.com
There is an extensions for your browser so that you can run local sites (localhost), on the emulated device.
30 min trial is free which is usually enough for a few tests.
I'm using Chrome's desktopCapture in an extension and I have an issue that I'm attempting to work around. Any help would be greatly appreciated. I cannot post any source, but the chrome extension itself is commonly available and used on the web.
Issue
The issue is with resize / dimension changes that may occur while desktopCapture is capturing / streaming to the server. These changes can often occur seemingly too fast for my client to handle, causing the client application to crash.
Solution
I'd like to get some event or notification when the capturing end detects a resize of the area being captured; for instance a window which has been clicked and is being dragged to resize it.
An alternative would be if the event.data can be queried for width / height.
Research
I've google'd and searched the chrome / webrtc issues; I've come up empty thus far. There really isn't any good implementation information available from what I've found.
Going through the Chromium codebase is not an option for me; I am not a C/C++ developer.
What I would like from You
If you have experience with the desktopCapture offering, please share what you know. If you don't have any idea what I'm asking or have nothing constructive to add, please ignore this and move on.
Commentary
As of July 17th 2015, it would appear that there is a bug or missing support for resize events in Chromes desktopCapture extension. I will file an enhancement request with them and see where that goes. It probably won't help that "normal" WebRTC streams aren't "expected" to change dimensions during streaming and thus it is not handled.
Attach the captured stream to a video element and listen for the onresize (onsize?) event. Should also work for hidden elements if you don't want to display something at the capturing end.