Closed
Bug 1185099
Opened 10 years ago
Closed 8 years ago
UI / Touch widget behavior fails on Fennec
Categories
(Web Compatibility :: Site Reports, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: capella, Assigned: karlcow)
References
()
Details
(Whiteboard: [country all] [js] [contactready])
Not sure who to cc: on this ... (adding kats 'cause maybe?)
On page [0] halfway down and below the gif, there is an image with a red vertical "sizer" widget [1] (terminology?) ... designed to allow swiping left/right for visual image compares.
This doesn't seen to work for Fennec (phone GS3 / table N7), though it works fine on desktop.
For Chrome, it works for both Desktop / Mobile.
[0] http://space.io9.com/this-shower-of-gamma-rays-are-from-a-flaring-blazar-5-b-1717123013
[1] https://www.dropbox.com/s/f2nkg5c1pe7lr8q/Screenshot_2015-07-17-16-46-05.png?dl=0
Comment 1•10 years ago
|
||
Hm, for me when I tap on the image to the left or the right of the red line the line slides over. I can't see to actually *drag* the red line, but I can get it to move where I want easily enough. But yeah, with Chrome I can drag it.
Looking at <div class="jx-slider"> thing in WebIDE they register a touchstart listener on it which updates the slider, but also registers a touchmove listener which further updates the slider. (First bug: they never unregister the touchmove listener, so every time you put your finger down on the image there's an additional touchmove listener). The actual bug appears to be inside the touchmove listener, where they pass "event" instead of "e" to the updateSlider function. Presumably this works in Chrome but doesn't work in Firefox. I think (but am not sure) that this is a known difference in behaviour between Chrome and Firefox, and presumably they only tested in Chrome.
Comment 2•10 years ago
|
||
In other words, in the following file: http://gawker-labs.com/slider/global.js this bit of code:
this.addEventListener("touchmove",function(e){e=e||t.event,e.preventDefault(),n.updateSlider(event,!1)}
should really look like this:
this.addEventListener("touchmove",function(e){e=e||t.event,e.preventDefault(),n.updateSlider(e,!1)}
(... and the touchstart listener should avoid registering the touchmove more than once)
| Reporter | ||
Comment 3•10 years ago
|
||
Nice! So my desktop handles it with the proper mouse events, and this is a page design issue.
kats, thanks for your time !
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Comment 4•10 years ago
|
||
If the page is still broken in Fennec, we should reopen this as a webcompat issue.
| Reporter | ||
Comment 5•10 years ago
|
||
Attaching the interesting bit of code from that page after manual de-obfuscate [0]
The bits on line 26, 32 refer to |event| vs. say |e| in that context, and line 26 specifically seems responsible for the behavior difference observed here.
) Chrome, Opera, and com.android.browser ... seem to handle this in mobile.
) FF Desktop works due to use of the mouse events listeners.
Chatted with arai on irc, who suggested maybe smaug for the DOM Event question?
[0] https://www.dropbox.com/s/nfo3j7orlyru2qa/bug1185099_snip.js?dl=0
Status: RESOLVED → REOPENED
Flags: needinfo?(bugs)
Resolution: WORKSFORME → ---
| Reporter | ||
Comment 6•10 years ago
|
||
ms2ger points out: Bug 218415 - Request for window.event object added to DOM to ease cross browser scripting
Comment 7•10 years ago
|
||
Has anyone reported the issue to the website?
| Reporter | ||
Comment 8•10 years ago
|
||
Switching to Tech Evangelism ...
"we may want to implement window.event although that is a super ugly API"
Component: General → Desktop
Product: Firefox for Android → Tech Evangelism
| Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(bugs)
Updated•10 years ago
|
Component: Desktop → Mobile
| Assignee | ||
Updated•10 years ago
|
OS: Unspecified → Android
Hardware: Unspecified → ARM
Whiteboard: [country all] [js] [contactready]
| Assignee | ||
Comment 9•10 years ago
|
||
| contact twitter | ||
Confirmed on a recent build of Firefox Android with version number as explained in Comment #1
io9.com is part of gawker publishing group.
They have a support center
http://help.gawker.com/customer/portal/emails/new
There are also on GitHub which might be easier to reach out the right person
https://github.com/gawkermedia
https://github.com/orgs/gawkermedia/people
Trying a first contact
http://twitter.com/MozWebCompat/status/625800358724435969
Assignee: nobody → kdubost
Status: REOPENED → ASSIGNED
| Reporter | ||
Comment 10•10 years ago
|
||
fyi, another (current) example of |gawker-labs.com/slider| mobile touch failure ... this time at Gizmodo
http://gizmodo.com/before-and-after-pics-of-californias-shrinking-salton-s-1735625267
Comment 11•10 years ago
|
||
Still an issue, re-tested in Nightly. I can pan the image back and forth, but the "divider" doesn't follow the finger like it does in Chrome. Karl, perhaps try again?
| Assignee | ||
Comment 13•9 years ago
|
||
Let me try again
http://twitter.com/MozWebCompat/status/753059423363354624
Flags: needinfo?(kdubost)
Updated•8 years ago
|
Priority: -- → P1
Comment 14•8 years ago
|
||
You have to click through to http://kinja-labs.com/slider/?img1=http://www.nasa.gov/sites/default/files/3c279_before_labels.jpg&img2=http://www.nasa.gov/sites/default/files/3c279_after_labels.jpg&start=50&color=red now, but this is working now.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 8 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: Tech Evangelism → Web Compatibility
Updated•2 years ago
|
Component: Mobile → Site Reports
You need to log in
before you can comment on or make changes to this bug.
Description
•