Open Bug 194540 Opened 17 years ago Updated 11 years ago
Content sink interruption fails if load is not in top window
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...
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.
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
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?
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.
I just downloaded the latest Phoenix build and it is also completely responsive doing the same test I performed in comment #4.
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?
I filed the following bugs to implement nsIWidget::GetLastInputEventTime(PRUint32& aTime) OS/2 - bug 194571 BeOS - bug 194572
You need to log in before you can comment on or make changes to this bug.