194540 - Content sink interruption fails if load is not in top window

Status: NEW

(Core :: Layout, defect, P3)

Description

[Boris Zbarsky [:bzbarsky]]

We have this code in the HTML content sink that interrupts the parser if there
recent mouse or key events so that we're a little more responsive if the user is
interacting with the document.

This fails to deal with the scenario described in
http://www.mozillazine.org/forums/viewtopic.php?p=47685#top though -- one page
loading in a background tab or different window while the user tries to interact
with another page.

Could we somehow keep global track of the event status for the whole UI event
queue, not just for the viewmanager of the loading document?  That may improve
perceived speed for a lot of people...

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I was just thinking about a similar problem in the context of doing
interruptible reflow. It would be really good to have a global-ish method that
tells us (*quickly*) whether there is any input pending.

Comment 2

[Kevin McCluskey (gone)]

This problem was solved on WIN32 by the fix for bug 165039. The fix for bug
165039 also put the infrastructure in place so it could be solved for Linux and
Mac. We need to implement nsIWidget::GetLastInputEventTime on those two platforms

Linux (bug 172499) 
Mac (bug 172501)

If the platform does not implement GetLastInputEventTime the content sink uses
the time cached in the viewmanager.

nsIWidget::GetLastInputEventTime(PRUint32& aTime) is defined to return the time
of any input event. (ie. it is *not* limited to events targeted at the nsIWidget
instance)

see http://lxr.mozilla.org/seamonkey/source/widget/public/nsIWidget.h#915

Comment 3

[Boris Zbarsky [:bzbarsky]]

Note that the Mozillazine comment I referenced is made by a _Windows_ user using
current trunk gecko....

I'll reassign those other bugs to people who may even work on them or
something....  Don't we also need bugs for the other widget implementations,
filed on the respective port owners?

Comment 4

[Kevin McCluskey (gone)]

I can not reproduce this problem using 2003022108 Mozilla build on 750Mhz WinXP
machine. If I start the load of large (3Mb) file) local file I can open other
tabs, interact with the menu, scroll, open other pages in new tabs, click on
links in these other pages.  Mozilla remains completely responsive. I also
performed the same test loading the lxr source of CSSFrameConstructor.

Before I made the change mentioned in bug 165039 and fixed the event starvation
issues related to native notification of PL_Events Mozilla would completely lock
up until the entire (3MB) page completed loading when doing the same test. These
fixes have been in the tree for months.

When I put this fixes in I also tested them on a 400Mhz WINNT machine. It was
also completely responsive back then.

I'm not sure what is causing the Mozillazine user's issues, since I can not
reproduce what he describes. Maybe his machine is substantially slower than
400Mhz?. Or maybe its a problem introduced by Phoenix?

" Don't we also need bugs for the other widget implementations,
filed on the respective port owners?"

Yes, we should.

Comment 5

[Kevin McCluskey (gone)]

I just downloaded the latest Phoenix build and it is also completely responsive
doing the same test I performed in comment #4. 

Comment 6

[Boris Zbarsky [:bzbarsky]]

Kein, would you mind filing those bugs, since you have the clearest grasp of
what it is that needs implementing so can describe it usefully in the bugs?

Comment 7

[Kevin McCluskey (gone)]

I filed the following bugs to implement
nsIWidget::GetLastInputEventTime(PRUint32& aTime)

OS/2 - bug 194571
BeOS - bug 194572