172499 - Need to implement nsIWidget::GetLastInputEventTime(PRUint32& aTime) on GTK+

Status: RESOLVED INACTIVE

(Core :: Widget: Gtk, defect, P5)

Description

[Kevin McCluskey (gone)]

this was broken off from bug 165039

To improve interactivity during long page loads we need to implement
nsIWidget::GetLastInputEventTime.

Since it is currently not implemented, Mozilla gets the last user input event
time from the viewmanager. The viewmanager only reports times for mouse and
keyboard events which occur in windows associated with a viewmanager. Other
mouse and keyboard events such as clicking in a window title bar are not
reported so moving a window while loading a long page is sluggish. For embedded
applications, clicking on native menus and interacting with native dialog boxes
is also sluggish because these mouse and keyboard events times are not recorded
in the viewmanager.


NS_IMETHOD GetLastInputEventTime(PRUint32& aTime) = 0;

Description:

Get the last user input event time in milliseconds. If there are any pending
native toolkit input events it returns the current time. All input events are 
included (ie. it is *not* limited to events targeted at this nsIWidget instance.

@param aTime Last user input time in milliseconds. This value can be used to
compare durations but can not be used for determining wall clock time. The value
returned is platform dependent, but is compatible with the expression 
PR_IntervalToMicroseconds(PR_IntervalNow()).

Comment 1

[Adam D. Moss]

> Other mouse and keyboard events such as clicking in a window title bar are not
> reported so moving a window while loading a long page is sluggish.

Interactive window moving and resizing don't require application
intervention under X11.  It's fair to say that the percieved speed
might suffer, though, if Moz can't respond to the resulting repaints
reasonably quickly (so should expose/repaint requests count as
outstanding 'native toolkit input events'?).

Comment 2

[slice1900]

Absolutely expose/repaint events should count, one of the biggest visual
annoyances for Mozilla is the fact that Mozilla windows behave so much
differently than other windows under X, in that there is often a noticeable lag
between the time part of a window is exposed and it is properly painted when
Mozilla is busy.  During even the load of a short page it looks terrible,
anything that could speed up this handling would make Mozilla on X look much
better from an end user perspective.  This may have been only seen as a problem
for Windows on long page loads, but it is noticeable on Linux even for a fairly
simple page.

It may seem trivial to some, but as Linux is just starting to make some very
small inroads into the desktop world, things like this really stand out from
people used to the more aesthetically pleasing experience they are used to.

Even if doing all this extra "unnecessary" painting as these events come up
slows down the actual wall clock page load times I think it is desireable,
because page loads aren't normally done while windows are being moved, and when
they are, the user is concerned with something else other than the waiting for
the page load and render to complete.

Comment 3

[Kevin McCluskey (gone)]

This method is used to determine if the parser should interrupt more frequently.
The parser should only interrupt more frequently when the user has moved the
mouse, entered keyboard input, clicked the mouse. 

It must only return User Input events. Not paint/expose events.  If there are
paint starvation issues on Linux they need to be addressed by looking at the
mechanism for PL_Event dispatch on Linux, *not* by interrupting the parser. 

Comment 4

[Boris Zbarsky [:bzbarsky]]

over to a real owner

Comment 5

[Mats Palmgren (inactive)]

Attachment: wip

Something like this perhaps?
BTW, what would be a good testcase for this bug?

Comment 6

[Boris Zbarsky [:bzbarsky]]

The best testcase is probably putting printfs in the mode-switching stuff in nsHTMLContentSink and seeing what it behaves like, esp in an embedding app when you interact with said embedding app's UI...

Comment 7

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1552613