Steps to reproduce: 1. open Gaia browser app 2. load https://m.facebook.com/ and log in if you aren't already 3. find a shared link in the newsfeed 4. click on the page's title to open it (note: there might be a URL in the text; clicking that doesn't show the bug) Actual results: The link opens *twice* -- there are two new tabs opened in the browser. Expected results: The link opens once -- just one new tab opened. I'm seeing this in a self-built v1.3 build on a hamachi. It did not occur in v1.2.
Created attachment 8363938 [details] screenshot showing example of where to click In this example, the bug: * does occur when tapping on "The Battle in Kiev: Two Killed in Ukraine Protest" * does NOT occur when topping on "http://t.co/E7PQlyk4ZD"
Ben, Dale, any idea what's going on here?
I'm not able to reproduce this on a recent 1.3 build on Keon. Waiting for regression window.
Switching to QA Wanted to check if we can reproduce this on the latest 1.3 build.
I was able to reproduce it on the latest 1.3 build. A link opens twice when I tapped the image with URL provided. For the test I used a couple different links along with the provided "http://t.co/E7PQlyk4ZD" Device: Buri 1.3 MOZ BuildID: 20140123004001 Gaia: 6fbeac2415f07f10de181f0877ddf67ee299b885 Gecko: e8f6bdf8db3d Version: 28.0a2 Firmware Version: v1.2-device.cfg
Okay - can you check if this reproduces on 1.1?
It doesn't reproduce on 1.1 Device: Buri 1.1 MOZ BuildID: 20140123041201 Gaia: c434fe9a0e823029796805e141cfa983cda2d246 Gecko: aa0ceb07a73e Version: 18.0 Firmware Version: v1.2-device.cfg
The regression window is a little wide. 10/14 has too builds, I wasn't able to test on later 10/14 build during the Facebook webpage didn't allow to put login credentials, the fields are blocked even after resetting, restarting, reflashing Last working build where is no duplicated links: Device: Buri 1.3 MOZ BuildID: 20131014040204 Gaia: f240abf567325d486c3d0434791b1d132cfa327a Gecko: 211337f7fb83 Version: 27.0a1 Firmware Version: v1.2-device-cfg The build where is FB login fields are blocked and couldn't test it: Device: Buri 1.3 MOZ BuildID: 20131014080339 Gaia: 74e7e69d98206bda5c517c0ada57d43de662913e Gecko: ab8e70fb76a8 Version: 27.0a1 Firmware Version: v1.2-device.cfg The first broken build with duplicated links: Device: Buri 1.3 MOZ BuildID: 20131015040202 Gaia: 17e871ae1f82699793e3cd28acda805ba724a8b6 Gecko: febfe3c7732b Version: 27.0a1 Firmware Version: v1.2-device.cfg
I've noticed something interesting. For me, I see the bug if I use a Release build, but not if I use a Debug build. (I built each manually, and I'm testing on a Hamachi.) I wonder what would be different between Debug and Release. Could this be timing related?
(In reply to Ted Clancy [:tedders1] from comment #9) > I've noticed something interesting. For me, I see the bug if I use a Release > build, but not if I use a Debug build. (I built each manually, and I'm > testing on a Hamachi.) > > I wonder what would be different between Debug and Release. > > Could this be timing related? Probably timing related :( Or do you see different assertions in logcat?
I've consulted with :kats, and this appears to be an issue with Facebook. They shouldn't be opening links on both Touch events and Click events. I'm assigning this to the Tech Evangelism team so they can reach out to Facebook.
(In reply to Ted Clancy [:tedders1] from comment #12) > I've consulted with :kats, and this appears to be an issue with Facebook. > They shouldn't be opening links on both Touch events and Click events. > > I'm assigning this to the Tech Evangelism team so they can reach out to > Facebook. Actually that's not right - if the issue hasn't reproduced in a past release, then that means it's on our end to resolve the problem. That might mean this is a problem with how we prioritize event handling in the DOM, so I'm sending this over to DOM: Events to look more.
If the issue wasn't present in past releases, I suspect that's due to timing differences. No one should be relying on timing differences.
Actually, ignore me. Letting the DOM Events team review this is probably a good idea.
I don't see any suspicious changes to event handling in http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=211337f7fb83&tochange=febfe3c7732b Bug 915757 landed, but was then also backed out, so it shouldn't have affected. Could gaia change Bug 925289 have caused this?
Oh, perhaps Bug 922896.
(In reply to Olli Pettay [:smaug] from comment #16) > I don't see any suspicious changes to event handling > in > http://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=211337f7fb83&tochange=febfe3c7732b > Bug 915757 landed, but was then also backed out, so it shouldn't have > affected. > > Could gaia change Bug 925289 have caused this? Don't think so - that bug deals with a desktop extension, which should not affect phone behavior.
(In reply to Olli Pettay [:smaug] from comment #17) > Oh, perhaps Bug 922896. Dale is going to investigate this.
Assigning based on comment 19. FWIW it still sounds like a timing issue to me. It's quite possible that this worked fine pre-APZ because if they loaded a page in their touchend handler then the click event would probably get dropped as the click detection happened in the content process. With APZ the click detection happens in the parent process and so might still be running while the content process is fetching the new page.
Yeh trying to get a working build to very now, but it we are sending a touch / mouse event and this was purely a timing issue, I think it will still have to be evangelism, I dont think we can revert system wide performance improvements due to buggy web content right?
Okay, it sounds like we have a decision to make here. According to what I’ve heard from :kats, :smaug, and :daleharvey, it’s wrong for Facebook to respond to both Touch and Click events. That could be considered the root cause of this problem. However, the problem wasn’t visible until we removed the 300ms delay between Touch and Click events (Bug 922896). That was a change made for better performance. Our options are: 1) Do nothing, but let Facebook know they have an issue (through our Platform Evangelism team); or 2) Revert Bug 922896, let Facebook know they have an issue, and then re-apply Bug 922896 at a future date after Facebook fixes their issue. (After the 1.4 release, most likely.) In the meantime, our performance will be worse. There’s also no guarantee that Facebook will ever fix their issue. To some degree, this is a question of what’s more important: performance or working around a Facebook glitch. I'm going to take this to our Product Manager.
I don't think we should be taking a performance hit in favor of working around a bug Facebook has. We do have a locked down partner connection with them, so I think a TE approach is the best path forward at this point. Karen - Can you coordinate with FB to fix this issue?
Colby, please review and let us know when we can expect a fix. Thank you.
Hmm... This is definitely an issue on our end. I'll look into it and report back.
This seems to have stopped happening for me sometime earlier this week.
The fix for this was released last week.