Last Comment Bug 327014 - Clicking <html:a> link in XUL document makes a browser window invisible
: Clicking <html:a> link in XUL document makes a browser window invisible
[sg:moderate] bfcache-related[rft-dl]
: fixed1.8.1, regression, verified1.8.0.2
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Brian Ryner (not reading)
: David Keeler [:keeler] (use needinfo?)
Depends on:
  Show dependency treegraph
Reported: 2006-02-13 08:46 PST by moz_bug_r_a4
Modified: 2007-04-19 02:14 PDT (History)
10 users (show)
dveditz: blocking1.7.13-
dveditz: blocking‑aviary1.0.8-
dveditz: blocking1.9a1+
dveditz: blocking1.8.1+
dveditz: blocking1.8.0.2+
bob: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

main xul (2.72 KB, application/vnd.mozilla.xul+xml)
2006-02-13 08:52 PST, moz_bug_r_a4
no flags Details
This is used to open main xul. (836 bytes, text/html)
2006-02-13 08:55 PST, moz_bug_r_a4
no flags Details
screenshot (45.77 KB, image/jpeg)
2006-02-13 09:03 PST, moz_bug_r_a4
no flags Details
simple testcase (873 bytes, text/html)
2006-02-13 09:07 PST, moz_bug_r_a4
no flags Details
patch (755 bytes, patch)
2006-03-06 19:52 PST, Brian Ryner (not reading)
roc: review+
roc: superreview+
dbaron: approval‑branch‑1.8.1+
timr: approval1.8.0.2+
Details | Diff | Splinter Review

Description moz_bug_r_a4 2006-02-13 08:46:38 PST
Clicking <html:a> link in XUL document makes a browser window invisible.

<window xmlns="">
  <p xmlns="">
    <a href="about:blank">a</a>

1. w = open("XUL-DOC");
2. Click the link on XUL-DOC.  Then about:blank is loaded.
3. Move mouse.  Then XUL-DOC's browser window becomes invisible.
4. w.history.back();
Then the browser UI is still invisible, but XUL-DOC's content elements are
displayed onto the browser UI.

Note: and trunk are affected. 1.0.x is not affected.
When bfcache is disabled, this bug is not reproducible.
On Linux, this bug is not reproducible. (I've tested on Windows XP and Linux.)

This bug could be used to exploit.  For example, if an attacker created a 
JavaScript game page and could convince a user to drag and drop two links
(about:config and javascript:...) onto the invisible Bookmarks Toolbar, and
click those bookmarks in sequence, then an attacker could run arbitrary code.
Comment 1 moz_bug_r_a4 2006-02-13 08:52:00 PST
Created attachment 211729 [details]
main xul
Comment 2 moz_bug_r_a4 2006-02-13 08:55:24 PST
Created attachment 211730 [details]
This is used to open main xul.
Comment 3 moz_bug_r_a4 2006-02-13 09:03:51 PST
Created attachment 211732 [details]
Comment 4 moz_bug_r_a4 2006-02-13 09:07:13 PST
Created attachment 211733 [details]
simple testcase
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2006-02-13 10:32:00 PST
Hmm... how's bfcache involved?
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2006-02-13 10:50:00 PST
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?
Comment 7 Daniel Veditz [:dveditz] 2006-02-13 10:50:10 PST
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060111 Firefox/

I don't get anything like your screenshot.
Comment 8 Daniel Veditz [:dveditz] 2006-02-13 10:52:06 PST
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?)
Comment 9 Daniel Veditz [:dveditz] 2006-02-13 10:57:33 PST
I did see the following on the console in a debug build:

JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIRDFService.GetDataSource]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: chrome://browser/content/search.xml :: initialize :: line 94"  data: no]
WARNING: waaah!, file c:/dev/ff15/mozilla/content/xul/document/src/nsXULPrototypeDocument.cpp, line 869
Comment 10 Daniel Veditz [:dveditz] 2006-03-01 12:01:25 PST
Bryner: we need a patch for this. If you aren't the right assignee can you name someone else?
Comment 11 Tim Riley [:timr] 2006-03-06 15:07:34 PST
This one is a blocker for  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?
Comment 12 Mike Schroepfer 2006-03-06 18:02:06 PST
ccing Roc as he may be able to help
Comment 13 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-03-06 18:13:47 PST
I'm on Linux, so I can't easily help.
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2006-03-06 19:16:05 PST
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....
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2006-03-06 19:16:40 PST
I might be able to work on this on Wed night, but not before...
Comment 16 Brian Ryner (not reading) 2006-03-06 19:52:25 PST
Created attachment 214273 [details] [diff] [review]

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.
Comment 17 Brian Ryner (not reading) 2006-03-06 19:53:52 PST
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 .
Comment 18 Brian Ryner (not reading) 2006-03-06 20:36:00 PST
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 19 Brian Ryner (not reading) 2006-03-06 21:35:29 PST
Comment on attachment 214273 [details] [diff] [review]

requesting branch approvals for this fix as well
Comment 20 Brian Ryner (not reading) 2006-03-06 21:35:52 PST
checked in on trunk only.
Comment 21 Tim Riley [:timr] 2006-03-06 22:45:39 PST
Comment on attachment 214273 [details] [diff] [review]

a=timr for drivers.  A simple fix for a blocker.  Excellent!
Comment 22 Brian Ryner (not reading) 2006-03-07 00:08:03 PST
checked in on both branches
Comment 23 David Baron :dbaron: ⌚️UTC-10 2006-03-07 09:24:54 PST
Comment on attachment 214273 [details] [diff] [review]

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)
Comment 24 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-03-07 14:39:27 PST
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.
Comment 25 Bob Clary [:bc:] 2006-03-09 13:24:55 PST
Comment 26 georgi - hopefully not receiving bugspam 2007-04-19 02:14:28 PDT
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)?

Note You need to log in before you can comment on or make changes to this bug.