778333 - Unable to click on links on http://autosport.com/

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Matt Brubeck (:mbrubeck)]

+++ This bug was initially created as a clone of Bug #775372 +++

Tapping links on http://autosport.com/ in Fennec does nothing; the tap highlight does not appear and the link is not opened.  (However, long-press on a link does produce the correct context menu.)  There are no errors logged.  This page does not appear to have touch event listeners.

Comment 1

[Wesley Johnston (:wesj)]

Something is preventing events from getting to this page for a long time. I think we end up receiving touchstart around the same time we receive SingleTap. With the timer stuff we're using to set our tapHighlight, we may have no taphighlight element when we receive SingleTap and so we just bail. In fact, SingleTap calls cancelTapHighlight, which kills our timer so that we never highlight anything.

It would be good to kill this race, but I'd like to know what's making this page so slow to get events too.

Comment 2

[Wesley Johnston (:wesj)]

I looked at our java->gecko event queue here, but things there look fine. At least the "sending event" and "done with event" messages for the touches and broadcast messages all seem to fly by very close to each other:

I/Gecko   ( 3273): nsAppShell: event 0x5fbef660 2
I/Gecko   ( 3273): nsAppShell::ScheduleNativeEventCallback pth: 0x1c1918 thread: 0x5cc56fa0 main: 0
I/Gecko   ( 3273): nsAppShell::PostEvent 0x5cc393d0 0
I/Gecko   ( 3273): nsAppShell: -- done event 0x5fbef660 2
I/Gecko   ( 3273): nsAppShell::ProcessNextNativeEvent 0
I/Gecko   ( 3273): nsAppShell: event 0x5cc393d0 0
I/Gecko   ( 3273): nsAppShell: -- done event 0x5cc393d0 0
...
I/Gecko   ( 3273): nsAppShell: event 0x5cc393d0 0
I/Gecko   ( 3273): nsAppShell: -- done event 0x5cc393d0 0
I/Gecko   ( 3273): nsAppShell::ProcessNextNativeEvent 0
I/Gecko   ( 3273): nsAppShell::PostEvent 0x5cc393d0 2
I/Gecko   ( 3273): nsAppShell::ScheduleNativeEventCallback pth: 0x1c1918 thread: 0x5cc56fa0 main: 0
I/Gecko   ( 3273): nsAppShell::PostEvent 0x5cc39530 0
I/Gecko   ( 3273): nsAppShell::PostEvent 0x5cc39690 19
I/Gecko   ( 3273): nsAppShell::ProcessNextNativeEvent 0
I/Gecko   ( 3273): nsAppShell: event 0x5cc393d0 2
I/Gecko   ( 3273): nsAppShell: -- done event 0x5cc393d0 2
I/Gecko   ( 3273): nsAppShell::ProcessNextNativeEvent 0
I/Gecko   ( 3273): nsAppShell: event 0x5cc39530 0
I/Gecko   ( 3273): nsAppShell: -- done event 0x5cc39530 0
I/Gecko   ( 3273): nsAppShell::ProcessNextNativeEvent 0
I/Gecko   ( 3273): nsAppShell: event 0x5cc39690 19
I/Gecko   ( 3273): nsAppShell: -- done event 0x5cc39690 19
I/Gecko   ( 3273): nsAppShell::ProcessNextNativeEvent 0


I also grabbed a profile using the built in profiler:
http://people.mozilla.com/%7Ebgirard/cleopatra/?report=fdb8e6900f04f16e2e3e9ae0c2c1e67338d78437

Looks like the page is doing tons of reflow/paint operations even though its fairly static. Need to figure out why.

Comment 3

[Wesley Johnston (:wesj)]

autosport is running a tiny, not quite right, countdown timer at the top of the page:

var eventdate = new Date("2 September 2012 12:00 GMT");
var startTime = (new Date()).getTime();
function countdown() {
  startTime+=500;
  count=Math.floor((eventdate.getTime()-(new Date(startTime)).getTime())/1000);
  if(count<=0) {
    document.getElementById("gpcountdown").innerHTML = "The "+gpname+" GP has already started!";
    return;
  }
  document.getElementById("gpcountdown").innerHTML = <time until the gp!>;
  setTimeout("countdown()",500);
}
window.onload = countdown;

Those constant innerHTML calls cause us to reflow and repaint, which is eating up time for taps and things to trigger. Removing the final setTimeout call or the innerHTML call causes the page to become responsive.

Comment 4

[Catalin Suciu [:csuciu]]

Good build: 12-07-2012
Bad build: 13-07-2012

Possible range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=46804c31366b&tochange=6489be1890c0

Comment 5

[Aaron Train [:aaronmt]]

There' over a 100 changesets in that range, can you use tinderbox-builds?

Comment 6

[Matt Brubeck (:mbrubeck)]

(In reply to Aaron Train [:aaronmt] from comment #5)
> There' over a 100 changesets in that range, can you use tinderbox-builds?

No need; this pretty much confirms that this is a regression from bug 769857.

Comment 7

[Wesley Johnston (:wesj)]

Yeah. There are two bugs here. One is the taphighlight race making clicks not work at all.

The other is that simple changes are causing way to much reflow. I guess we should split the reflow stuff off to another bug. I'm cc'ing ehsan to find out if there is a bug covering it already? or maybe to get advice on what further debugging to do?

Comment 8

[Matt Brubeck (:mbrubeck)]

Fixed for Fx17 by backing out bug 769857:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4ef483246388

In bug 775372 I requested Aurora approval for the backout.

Comment 9

[Matt Brubeck (:mbrubeck)]

Backout landed on Aurora:
https://hg.mozilla.org/releases/mozilla-aurora/rev/a793894365e7

Comment 10

[Ryan VanderMeulen [:RyanVM]]

(In reply to Matt Brubeck (:mbrubeck) from comment #8)
> Fixed for Fx17 by backing out bug 769857:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/4ef483246388
> 
> In bug 775372 I requested Aurora approval for the backout.

https://hg.mozilla.org/mozilla-central/rev/4ef483246388

Comment 11

[(no longer active)]

(In reply to comment #7)
> The other is that simple changes are causing way to much reflow. I guess we
> should split the reflow stuff off to another bug. I'm cc'ing ehsan to find out
> if there is a bug covering it already? or maybe to get advice on what further
> debugging to do?

I'm not sure what you mean here.