327014 - Clicking <html:a> link in XUL document makes a browser window invisible

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[moz_bug_r_a4]

Clicking <html:a> link in XUL document makes a browser window invisible.

XUL-DOC:
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <p xmlns="http://www.w3.org/1999/xhtml">
    <a href="about:blank">a</a>
  </p>
</window>

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:
1.5.0.1 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]

Attachment: main xul

Comment 2

[moz_bug_r_a4]

Attachment: This is used to open main xul.

Comment 3

[moz_bug_r_a4]

Attachment: screenshot

Comment 4

[moz_bug_r_a4]

Attachment: simple testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm... how's bfcache involved?

Comment 6

[Boris Zbarsky [:bzbarsky]]

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]]

WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I don't get anything like your screenshot.

Comment 8

[Daniel Veditz [:dveditz]]

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]]

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]]

Bryner: we need a patch for this. If you aren't the right assignee can you name someone else?

Comment 11

[Tim Riley [:timr]]

This one is a blocker for 1.5.0.2.  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]

ccing Roc as he may be able to help

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm on Linux, so I can't easily help.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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 [:bzbarsky]]

I might be able to work on this on Wed night, but not before...

Comment 16

[Brian Ryner (not reading)]

Attachment: 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.

Comment 17

[Brian Ryner (not reading)]

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)]

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)]

Comment on attachment 214273 [details] [diff] [review]
patch

requesting branch approvals for this fix as well

Comment 20

[Brian Ryner (not reading)]

checked in on trunk only.

Comment 21

[Tim Riley [:timr]]

Comment on attachment 214273 [details] [diff] [review]
patch

a=timr for drivers.  A simple fix for a blocker.  Excellent!

Comment 22

[Brian Ryner (not reading)]

checked in on both branches

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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)

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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] (inactive)]

v 1.8.0.2/winxp/20060308

Comment 26

[georgi - hopefully not receiving bugspam]

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)?