Closed Bug 1263426 Opened 6 years ago Closed 6 years ago

Can't click to add per-year graph lines, on nsidc.org "Charctic Interactive Sea Ice Graph", if touch events are enabled

Categories

(Web Compatibility :: Desktop, defect)

Unspecified
Linux
defect
Not set
normal

Tracking

(firefox45 unaffected, firefox46+ wontfix, firefox47+ unaffected, firefox48+ unaffected)

VERIFIED FIXED
Tracking Status
firefox45 --- unaffected
firefox46 + wontfix
firefox47 + unaffected
firefox48 + unaffected

People

(Reporter: jl.livemont, Assigned: adamopenweb)

References

()

Details

(Keywords: regression, Whiteboard: [country-all][sitewait])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150930122151

Steps to reproduce:

browse http://nsidc.org/arcticseaicenews/charctic-interactive-sea-ice-graph/ and click on the right table with years curves


Actual results:

nothing... Click has no effect, i saw nothing in consoles.
No new curve plotted.
This work well with firefox 0.41 and no more with .45 and 0.47 developper under linux fedora 23 64 bits (kernel 4.4.6-300.fc23.x86_64).
This work well with all version of firefox under windows and mac OS.



Expected results:

A new curve should be plotted on the graph.
I know that it could be linked to linux libraries but could you help to determine what's going wrong?
Thanks a lot for your amazing work.
Bests Regards
Component: Untriaged → SVG
OS: Unspecified → Linux
Product: Firefox → Core
This works for me in Firefox 45 on 64-bit Ubuntu 16.04 (kernel 4.4.0-18-generic, though kernel probably doesn't matter much).

Are your Firefox 45 and 47 builds from fedora's package manager, or are they downloaded directly from Mozilla's website? (That distinction can help identify or rule out some potential differences that might be causing the problem.)
Flags: needinfo?(jl.livemont)
Hello Daniel.
The firefox 0.45.0.1 is the firefox rpm downloaded from fedora official repo
The firefox 0.47.0a2 has benn downloaded from https://www.mozilla.org/fr/firefox/developer/ the archive file was firefox-47.0a2.fr.linux-x86_64.tar.bz2
Bests regards.
Jean-Luc
Flags: needinfo?(jl.livemont)
Could you test with the official build for Linux?
https://www.mozilla.org/en-US/firefox/all/
Flags: needinfo?(jl.livemont)
(It sounds like JL did already test & reproduce the issue in an official mozilla-produced Developer Edition build. I expect that would rule out any fedora-specific packaging quirks.)
JL, could you see if you can reproduce the bug today with an official Firefox 41 release, though?  You said in comment 0 that Firefox 41 was unaffected -- but I'm wondering if it's really just that you got a system library update during the time since you were running Firefox 41, and that library update is what introduced the bug.

So: I tentatively predict that you *will* see the bug today in Firefox 41, even though you didn't see it back when 41 was the actual release version. It would be great if you could test my prediction.

You can download a tarball of Firefox 41 from here:
  https://ftp.mozilla.org/pub/firefox/releases/41.0/linux-x86_64/fr/

Thanks!
Hello and thanks for spending time on this problem.

Ok so let's summarize...
with firefox 0.41 rpm from fedora it's ok
with firefox 0.45 rpm from fedora (actual) it is not ok
with firefox 0.47.0a2 developper from https://www.mozilla.org/fr/firefox/developer/ it is not ok
with firefox 0.45 from https://www.mozilla.org/en-US/firefox/all/ it is ok
with firefox 0.41 from https://ftp.mozilla.org/pub/firefox/releases/41.0/linux-x86_64/fr/ it is ok

Why do you use fedora so??? ;)

Let me know the result of this.
Flags: needinfo?(jl.livemont)
If there are mozilla Firefox builds one of which is OK and one isn't please find a regression range using -moz-regression. http://mozilla.github.io/mozregression/ and report it here in this bug.
Flags: needinfo?(jl.livemont)
No, execpt the firefox 0.47.0a2 developper, i did not find any release where the problem occurs.
It's seems to be a problem of rpm packaging from fedora.
Flags: needinfo?(jl.livemont)
That's precisely what I meant you found an issue on mozilla firefox located somewhere between 45 (OK) and 47 (not OK).
Flags: needinfo?(jl.livemont)
I would be glad to help but i have been unable to found the release date to fill moz-regression arguments. 
Every official build are working. I did not found any official build for 0.47 while browsing https://ftp.mozilla.org/pub/firefox/releases/.
How can i do?
Flags: needinfo?(jl.livemont)
You don't need a release date, use today's date.
Flags: needinfo?(jl.livemont)
Today would presumably be a "bad" date for mozregression, but JL also needs to provide some "good" date.

According to https://wiki.mozilla.org/RapidRelease/Calendar, Firefox 45 became the Nightly version on 2015-10-29 -- so you should probably be OK to use:

> mozregression --good 2015-10-29 -a "http://nsidc.org/arcticseaicenews/charctic-interactive-sea-ice-graph/"

Alternately, if you want to go back as far as Firefox 41, you could do:
> mozregression --good 2015-05-11 -a "http://nsidc.org/arcticseaicenews/charctic-interactive-sea-ice-graph/"

Either of those commands should first test a build from that "good" date, and you can verify that it is in fact good. Then it'll test the latest build, and you can verify that it's bad. Then it will bisect to figure out when things switched from good to bad.
I'm tagging your comment as "obsolete" (to auto-collapse it) and I'm quoting the relevant part of it, so it won't make this bug page quite so tall.

(In reply to JL Livémont from comment #13)
> 13:16.28 INFO: Last good revision: 9aa45a7563473b25a5e9041981b21d61545d707b
> 13:16.28 INFO: First bad revision: abe200b244a551c42477e591fd413255f3424f5c
> 13:16.28 INFO: Pushlog:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=9aa45a7563473b25a5e9041981b21d61545d707b&tochange=abe2
> 00b244a551c42477e591fd413255f3424f5c
> 
> 13:17.55 INFO: Looks like the following bug has the changes which introduced
> the regression:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1217515

That is... odd.  Are you on a device with a touchscreen, by any chance?  If so, I can conceivably see how that patch might've broken this for you... but otherwise, I'm a bit mystified as to why this would be broken for you (on Fedora) but not me (on Ubuntu).
Flags: needinfo?(jl.livemont)
OK, I can confirm locally that this site is broken (with the symptoms described in comment 0 -- no effect when clicking on the years) if I manually enable touch events by setting dom.w3c_touch_events.enabled to 1 (enabled).

(Its default value -- 2 -- means "autodetect", which I'm guessing is evaluating to "enabled" in JL's case.)

Botond, looks like you worked on bug 1217515 (regressing bug) and other touch-events-related things -- could you take a look here?  Not sure whether this is our bug, or a site bug [if the site uses touch events somehow], or what.
Status: UNCONFIRMED → NEW
Component: SVG → DOM: Events
Ever confirmed: true
Flags: needinfo?(botond)
Version: 45 Branch → Trunk
Setting status flags to the best of my knowledge. I believe this bug affects releases as far back as Firefox 46 (currently on Beta) for people with JL's system configuration (for whom "autodetect" evaluates to enabled), because:
 - Firefox 46 received a backport for the regressing bug -- bug 1217515.
 - Firefox 46 has GTK3 support enabled, which is needed for bug 1217515 to do anything.

(Mozilla's Firefox 45 builds should be unaffected because they do not have GTK3 support enabled, as of bug 1245476 -- and the regressing bug seems to be GTK3-specific in the way that it checks things.  I wouldn't be surprised if Fedora elected to keep gtk3 enabled in their Firefox 45 build configuration, though, which is why JL is seeing this in his Fedora-packaged Firefox 45 build.)
Summary: Firefox 0.45.0..1 stop working with web site http://nsidc.org/arcticseaicenews/charctic-interactive-sea-ice-graph/ → Can't click to add per-year graph lines, on nsidc.org " Charctic Interactive Sea Ice Graph", if touch events are enabled
Flags: needinfo?(jl.livemont)
(In reply to Daniel Holbert [:dholbert] from comment #14)
> I'm tagging your comment as "obsolete" (to auto-collapse it) and I'm quoting

> That is... odd.  Are you on a device with a touchscreen, by any chance?  If
> so, I can conceivably see how that patch might've broken this for you... but
> otherwise, I'm a bit mystified as to why this would be broken for you (on
> Fedora) but not me (on Ubuntu).

No problem for the comment, i didn't know which part could help you, so...
For the hardware of my notebook Asus UX501J, it uses a touchpad and a touchscreen but none were working.
(In reply to JL Livémont from comment #19)
> here is the lshw output (you can obselete the comment after you have find
> the usefull part ;) )

For future reference, the recommended way to attach a long piece of output to a bug is to add it as an attachment. Note that there is a "paste text as attachment" feature on the "Attach File" page, so there is no need to create a local file.
Flags: needinfo?(botond)
Flags: needinfo?(botond)
Attachment #8740532 - Attachment description: lshw output → lshw output (from JL Livémont)
Flags: needinfo?(botond)
I can reproduce the issue on today's Nightly on a touchscreen Linux laptop. Setting dom.w3c_touch_events.enabled to 0 makes the problem go away.
When touch support is enabled, the year labels don't have "click" handlers, they have "touchstart" handlers instead.

The page's JS contains the following code (minified, then prettified by devtools):

  on: function (t, e) {
    var n = e;
    return _e && 'click' === t && (t = 'touchstart', n = function (t) {
      t.preventDefault(),
      e()
    }),
    this.element['on' + t] = n,
    this
  },

As far as I can tell, this code is replacing "click" handlers with "touchstart" handlers. The variable "_e" is set if touch event support is present, as detected by "document.documentElement.ontouchstart" being defined (which corresponds to dom.w3c_touch_events.enabled being set to 1, or to 2 and the system detecting touch event support).
Based on comment 23, I believe this is a bug in the site; moving to Tech Evangelism. Let me know if you disagree.
Component: DOM: Events → Desktop
Product: Core → Tech Evangelism
Does the issue happen also in Chrome (I think they support touch events too, though, is it Windows only?).
Who has a fancy Windows laptop to test this? -- According to Bug 1244402 this should be broken there too (at least in Nightly).
My wife has a Yoga 700 I can try it on tonight if nobody beats me to it.
Flags: needinfo?(ryanvm)
Confirmed that clicking on the year labels doesn't work in Chrome on a Windows touch device either.
Flags: needinfo?(ryanvm)
(Or in Firefox Nightly on Windows)
Summary: Can't click to add per-year graph lines, on nsidc.org " Charctic Interactive Sea Ice Graph", if touch events are enabled → Can't click to add per-year graph lines, on nsidc.org "Charctic Interactive Sea Ice Graph", if touch events are enabled
Do we know if this issue is widespread? If it also doesn't work in chrome, I am a bit less worried. 
Daniel, are you working on this or just continuing the investigation? 
We can still take a patch in beta for tomorrow's or Monday's beta/RC builds. But this is more likely going to ship in 46.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #30)
> Do we know if this issue is widespread?

No.

> Daniel, are you working on this or just continuing the investigation?

Was just helping with investigation/triage.

> We can still take a patch in beta for tomorrow's or Monday's beta/RC builds.
> But this is more likely going to ship in 46.

That's probably fine. Given recent comments here, this is a bug in the site, and it's simply broken for *any* browser that supports touch events. (We should do outreach, but we shouldn't necessarily let this site's breakage block us from shipping support for touch events, unless this were an extremely high-traffic site.)
Flags: needinfo?(dholbert)
I have made tests on my side...
On my laptop

Google chrome Version 49.0.2623.112 (64-bit) under fedora23 working well with touchpad and touchscreen

firefox 0.45.2 under windows 10 64 bits working well with touchpad and touchscreen

internet explorer 11.162.10586.0 under windows 10 64 bits working well with touchpad and touchscreen

google chrome 50.0.2661.75 m under windows 10 64 bits not working with touchpad but working with touchscreen
(In reply to JL Livémont from comment #32)
> Google chrome Version 49.0.2623.112 (64-bit) under fedora23 working well
> with touchpad and touchscreen

Can you check if chrome on fedora has touch events support? If you start Chrome, open the Chrome developer tools, go to the console, and type in "document.documentElement.ontouchstart" and hit enter, you should see either "null" or "undefined" as the output. If you see "undefined" that means the touch events are not supported. That's what I see on OS X, for example. On my Windows touch-enabled device I see "null". I don't have a Linux touch-enabled device to check.

> firefox 0.45.2 under windows 10 64 bits working well with touchpad and
> touchscreen

Yup, touch events is disabled in FF 45 on windows.

> internet explorer 11.162.10586.0 under windows 10 64 bits working well with
> touchpad and touchscreen

IE also doesn't appear to support touch events on my Windows touch device. I think they support pointer events instead.

> google chrome 50.0.2661.75 m under windows 10 64 bits not working with
> touchpad but working with touchscreen

This matches what I'm seeing.
Thanks for the extra explanation! Even though I want everyone's interactive sea ice graphs to work beautifully, wontfix for 46 as we are too close to release.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #33)

> Can you check if chrome on fedora has touch events support? 
You are right: the answer is undefined.
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #34)
> Thanks for the extra explanation! Even though I want everyone's interactive
> sea ice graphs to work beautifully, wontfix for 46 as we are too close to
> release.

Thanks, they is no emergency.
The goal was to let know to the firefox team it could be a problem to let you fix it.
And to let know to http://nsidc.org/ team they could change the web site code to avoid such problem.
I'm very impressed of the reactivity and the care you take on my ask of support. :)
Thanks for all. 
Let me know if you need help for further testing (in this case or any where my configuration could be usefull).
Adam, can you try to get in touch with the site?

See Comment #23 for the offending code. The recommended fix would probably just be to only listen for click events -- a touch event will eventually end up as a synthetic click event (and I think most mobile browsers have removed the 300ms click delay by now).
Flags: needinfo?(astevenson)
Whiteboard: [country-all][needscontact]
I left a voicemail and sent an email to Kate Heightley, who should be able to help.

http://nsidc.org/about/bios/heightley.html
Assignee: nobody → astevenson
Flags: needinfo?(astevenson)
Whiteboard: [country-all][needscontact] → [country-all][sitewait]
Received a very nice response and they are able to reproduce the bug. They are planning to do some bug fixes and additional feature development for the Charctic website in June. This bug has been added to the project's backlog and they will reach out if they require any help.
Status: NEW → ASSIGNED
Is this resolved now? I haven't seen reports from other sites so if Chartic fixed the issue on their end we can go ahead and close this issue.
Flags: needinfo?(jl.livemont)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #40)
> Is this resolved now? I haven't seen reports from other sites so if Chartic
> fixed the issue on their end we can go ahead and close this issue.

It doesn't look like Charctic fixed the issue on their side yet - I can still reproduce the same problem today.
I took a look at the web site http://nsidc.org/arcticseaicenews/charctic-interactive-sea-ice-graph/
and the click event is working :)
Thanks everybody!
Yep, confirmed as FIXED. Thx everyone.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Based on comment 43, 47 and 48 are unaffected. Please let me know if that is not the case.
[closing out needinfo (addressed in comment 42) and marking as "verified" based on comment 43.]
Status: RESOLVED → VERIFIED
Flags: needinfo?(jl.livemont)
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.