2.72 KB, application/vnd.mozilla.xul+xml
836 bytes, text/html
45.77 KB, image/jpeg
873 bytes, text/html
755 bytes, patch
|Details | Diff | Splinter Review|
Hmm... how's bfcache involved?
I don't see the problem with "simple testcase", but "This is used to open main xul" is definitely showing the problem on Linux. I'm guessing that we're messing with the wrong widgets, but not sure. Bryner, can you reproduce this? Do you have time to look into it?
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060111 Firefox/126.96.36.199 I don't get anything like your screenshot.
Nevermind, I had bfcache turned off. Works a treat in the default configuration. (What in the world does bfcache have to do with making chrome go away?)
Bryner: we need a patch for this. If you aren't the right assignee can you name someone else?
This one is a blocker for 188.8.131.52. We need some action on it! BZ, dbaron, mrbkap- can you work on this? Schrep- Is there a name you can give us to work on this?
ccing Roc as he may be able to help
I'm on Linux, so I can't easily help.
I see the problem on Linux with the testcase in comment 2, fwiw. I don't see the Windows thing, but I get a transparent window for a bit, then lots of asserts and chrome painting is busted....
I might be able to work on this on Wed night, but not before...
Created attachment 214273 [details] [diff] [review] patch Here's what causes the bug to happen: - we cache the xul document into bfcache - when you move the mouse, we get a reflow on the old document (this is suspicious and it seems like we shouldn't) - during reflow, the ContainerFrame code sees a XUL document with no parent (because it's been unhooked) and no background specified, and thinks we must be a toplevel chrome window that wants to be translucent. - the translucency bit is set on the native window and it goes poof It looks like things don't work quite the same way on gtk which is why this bug doesn't appear on Linux. Many thanks to roc for helpling me debug.
Oops, I hit submit before I meant to. This patch fixes the immediate problem by ensuring that the document has a container (that is, a docshell) before allowing it to be set as translucent. We should also investigate why a reflow is happening on the cached document. I'll file a separate bug on that .
I filed bug 329580 on the reflow problem. I referenced the testcase from this bug, and therefore also marked that one security-sensitive. If anyone feels strongly that the reflow bug should _not_ be security-sensitive (and I can certainly see why we'd want it not to be), we should come up with a testcase for it that's not so obviously exploitable.
Comment on attachment 214273 [details] [diff] [review] patch requesting branch approvals for this fix as well
checked in on trunk only.
Comment on attachment 214273 [details] [diff] [review] patch a=timr for drivers. A simple fix for a blocker. Excellent!
checked in on both branches
Comment on attachment 214273 [details] [diff] [review] patch a=dbaron, although I wonder whether it would be cleaner to make the aView->GetWidget() (or is it the SetWindowTranslucency) call do the right thing (since it seems to be manipulating a window that it doesn't control in this case)
The problem is that SetWindowTranslucency needs to search up the window hierarchy internally to find the "right" window. I'll probably fix this during view removal/widget wrangling.
found this xul related bug from thunderbird's release notes. is it possible thunderbird to display xul/xml in preview pane (without using iframe/object and xbl bindings)?