Bug 107410 - Should update compositing state when an out-of-view fixed position element becomes in-view
Summary: Should update compositing state when an out-of-view fixed position element be...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Normal
Assignee: Xianzhu Wang
URL: http://demo.phpmyadmin.net/STABLE/
Keywords: InRadar, Regression
Depends on:
Blocks:
 
Reported: 2013-01-20 20:15 PST by Kevin M. Dean
Modified: 2013-01-23 14:26 PST (History)
5 users (show)

See Also:


Attachments
Patch (5.62 KB, patch)
2013-01-23 12:40 PST, Xianzhu Wang
no flags Details | Formatted Diff | Diff
Patch (5.97 KB, patch)
2013-01-23 13:40 PST, Xianzhu Wang
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin M. Dean 2013-01-20 20:15:04 PST
When I load PHPMyAdmin, it uses a frameset with a database list on the left and menu and content on the right. The menu in the right frame at the top is in a fixed position div. When I first open PHPMyAdmin the menu is there, but once I click on databases in the left frame, the  right frame loads a new page and the fixed position div no longer displays. The white block of space also scrolls with the page so it's not even fixed positioned. If I open Web Inspector and turn off the css for positon: fixed;, the menu then appears and I can toggle fixed back on, causing it to work as expected and it remains until I load new content into the frame and then it's gone again. If I load the right frame pages into a new tab or window, the fixed div appears fine. It's only when loading into a frameset that the problem is occurring.
Comment 1 Alexey Proskuryakov 2013-01-21 10:21:10 PST
Confirmed with <http://demo.phpmyadmin.net/STABLE/> (login:root, empty password). I'm getting a blank menu bar even on initial load.
Comment 2 Alexey Proskuryakov 2013-01-21 10:21:24 PST
<rdar://problem/13053090>
Comment 3 Simon Fraser (smfr) 2013-01-21 11:28:01 PST
Tried to regress this but demo.phpmyadmin.net is way too slow.
Comment 4 Simon Fraser (smfr) 2013-01-21 11:55:02 PST
This is the only likely cause in that range: http://trac.webkit.org/changeset/139461
Comment 5 Xianzhu Wang 2013-01-23 10:52:50 PST
Verified on Chromium ToT with "--enable-fixed-position-creates-stacking-context --enable-fixed-position-compositing".
Comment 6 Xianzhu Wang 2013-01-23 12:34:54 PST
Just tested without http://trac.webkit.org/changeset/139461 and the bug still existed, so this seems not a recent regression.

When a non-compositing page contains some not-composited fixed position element because of bounds out-of-view, when the element changes position and RenderLayerCompositor::updateCompositingLayers() is called, the function may return early because of "if (!m_reevaluateCompositingAfterLayout && !m_compositing)" without updating the compositing layers.

Should set m_reevaluateCompositingAfterLayout when a fixed position element is not composited because of bounds out-of-view.
Comment 7 Xianzhu Wang 2013-01-23 12:40:22 PST
Created attachment 184286 [details]
Patch
Comment 8 Xianzhu Wang 2013-01-23 13:30:02 PST
Comment on attachment 184286 [details]
Patch

Sorry for the wrong version of the expected file.
Comment 9 Xianzhu Wang 2013-01-23 13:40:41 PST
Created attachment 184301 [details]
Patch
Comment 10 WebKit Review Bot 2013-01-23 14:26:19 PST
Comment on attachment 184301 [details]
Patch

Clearing flags on attachment: 184301

Committed r140593: <http://trac.webkit.org/changeset/140593>
Comment 11 WebKit Review Bot 2013-01-23 14:26:23 PST
All reviewed patches have been landed.  Closing bug.