1053946 - [Browser API] stop() intermittently failing

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Ben Francis [:benfrancis]]

On Firefox OS current master...

STR:
* Focus Rocketbar
* Type planet.mozilla.org
* Hit enter
* Hit stop

Expected:
* Page stops loading

Actual:
* Page continues loading

It appears that the stop() method is being called but itermittently has no effect.

It is called here:
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/browser_mixin.js#L153

Could someone help me to debug this issue to find out what's going on, and verify whether the issue is in Gecko or Gaia?

Comment 1

[Ben Francis [:benfrancis]]

Kan-Ru, would you be able to take a look at this?

Comment 2

[Kan-Ru Chen [:kanru] (UTC+9)]

Yes, I can reproduce this on Flame.

Comment 3

[Kan-Ru Chen [:kanru] (UTC+9)]

Task tracer shows that the "stop" message was dispatched the child process immediately but was delayed for a very long time. I think the child side "stop" handler hadn't got a chance to run before the page finished loading. I'm still investigating what had caused the delay.

Comment 4

[Kan-Ru Chen [:kanru] (UTC+9)]

Attachment: Task Tracer

From the task tracer output (with some info omitted), we could find that although the IPC message was enqueued very early it was blocked by the Layout & Style event on the main thread.

Comment 5

[Kan-Ru Chen [:kanru] (UTC+9)]

If the layout is interruptible, the nsPresShell should do incremental layout in "deadline" and also check interrupts.

The default deadline is 1s

https://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#8959

Interrupt is checked by

https://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp?rev=6b96313c0e42#2701

The puppetWidget doesn't support HasPendingInput so currently no event could interrupt reflow in content process.

So we should at least could check new IPC messages in 1s resolution. But we didn't. So the question is why the Main thread didn't consume new IPC messages during the interruptible reflow.

Comment 6

[Kan-Ru Chen [:kanru] (UTC+9)]

Okay, this is a rather fundamental issue. The layout code is blocking the main thread. On Desktop when we are laying out such big page the whole UI is frozen. On a e10s enabled desktop browser, the stop button also can't interrupt and stop the page layout.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Could we perhaps inject something to http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp?rev=9ad8af59efe3&mark=2681-2682#2681 


Hmm, maybe not, since the stop message from parent doesn't probably even get handled before the
reflow is done.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Closing as we are not working on Firefox OS anymore.