Bug 119836 – [GTK] ChromeClient::paint is susceptible to system time changes

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[snyh]

In Source/WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp:ChromeClient::paint.

There has check timeUntilNextDisplay > 0  to reduce the no necessary painting, but you forget to check timeSinceLastDisplay's value can be an minus!!!

please add 
this code before " if (timeUntilNextDisplay > 0) { "


-------------------------------------------------------------
if (timeSinceLastDisplay < 0) { // We can go back to the past in computer World:)
    timeUntilNextDisplay = 0;
}
------------------------------------------------------------------

[Zan Dobersek]

Do you have a reproducible test case that shows the problem?

Technically, timeSinceLastDisplay can end up being negative, but it would in the worst case simply cause skipping one paint (dropping a frame).
This can be avoided by using WTF::monotonicallyIncreasingTime() instead of WTF::currentTime().

[snyh]

reproducible test case is very easy

set the system time go back to past

[snyh]

It's not only dropping one frame, it freeze the whole GUI rendering!!!(only webkitgtk, qtwebkit hasn't this problem)

You can run any GUI program based on webkitgtk and then adjust system time go back one hour(or more) then any GUI is freeze. 




(In reply to comment #1)
> Do you have a reproducible test case that shows the problem?
> 
> Technically, timeSinceLastDisplay can end up being negative, but it would in the worst case simply cause skipping one paint (dropping a frame).
> This can be avoided by using WTF::monotonicallyIncreasingTime() instead of WTF::currentTime().

[snyh]

m_lastDisplayTime = currentTime() is update too later! (so used m_lastDisplayTime and update it immediately is a good idea) 

So "double timeSinceLastDisplay = currentTime() - m_lastDisplayTime"
timeSinceLastDisplay is always an very big negative number ( minus 3000+ is we go to past one hour) until one hour past!


(In reply to comment #1)
> Do you have a reproducible test case that shows the problem?
> 
> Technically, timeSinceLastDisplay can end up being negative, but it would in the worst case simply cause skipping one paint (dropping a frame).
> This can be avoided by using WTF::monotonicallyIncreasingTime() instead of WTF::currentTime().

[Zan Dobersek]

(In reply to comment #3)
> It's not only dropping one frame, it freeze the whole GUI rendering!!!(only webkitgtk, qtwebkit hasn't this problem)

Yeah, I was wrong - didn't thought of the possibility of changing the system date to irrational values.

(In reply to comment #4)
> m_lastDisplayTime = currentTime() is update too later! (so used m_lastDisplayTime and update it immediately is a good idea) 

That part is just fine - m_lastDisplayTime is assigned the new value when the last display is actually complete.

[Zan Dobersek]

Created attachment 209224 [details]
Patch

[Zan Dobersek]

Comment on attachment 209224 [details]
Patch

Clearing flags on attachment: 209224

Committed r154380: <http://trac.webkit.org/changeset/154380>

[Zan Dobersek]

All reviewed patches have been landed.  Closing bug.