The default bug view has changed. See this FAQ.

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

RESOLVED FIXED

Status

()

Core
Security
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: moz_bug_r_a4, Assigned: Brian Ryner (not reading))

Tracking

({fixed1.8.1, regression, verified1.8.0.2})

Trunk
x86
Windows XP
fixed1.8.1, regression, verified1.8.0.2
Points:
---
Bug Flags:
blocking1.7.13 -
blocking-aviary1.0.8 -
blocking1.9a1 +
blocking1.8.1 +
blocking1.8.0.2 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate] bfcache-related[rft-dl])

Attachments

(5 attachments)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 211729 [details]
main xul
(Reporter)

Comment 2

11 years ago
Created attachment 211730 [details]
This is used to open main xul.
(Reporter)

Comment 3

11 years ago
Created attachment 211732 [details]
screenshot
(Reporter)

Comment 4

11 years ago
Created attachment 211733 [details]
simple testcase
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:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

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?)
Assignee: dveditz → bryner
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
Flags: blocking1.9a1?
Flags: blocking1.8.0.2?
Bryner: we need a patch for this. If you aren't the right assignee can you name someone else?
Flags: blocking1.9a1?
Flags: blocking1.9a1+
Flags: blocking1.8.1+
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.2+
Flags: blocking1.7.13-
Flags: blocking-aviary1.0.8-
Keywords: regression
Whiteboard: bfcache-related

Comment 11

11 years ago
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

11 years ago
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...
(Assignee)

Comment 16

11 years ago
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.
Attachment #214273 - Flags: superreview?(roc)
Attachment #214273 - Flags: review?(roc)
(Assignee)

Comment 17

11 years ago
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 .
(Assignee)

Comment 18

11 years ago
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.
Attachment #214273 - Flags: superreview?(roc)
Attachment #214273 - Flags: superreview+
Attachment #214273 - Flags: review?(roc)
Attachment #214273 - Flags: review+
(Assignee)

Comment 19

11 years ago
Comment on attachment 214273 [details] [diff] [review]
patch

requesting branch approvals for this fix as well
Attachment #214273 - Flags: approval1.8.0.2?
Attachment #214273 - Flags: approval-branch-1.8.1?(dbaron)
(Assignee)

Comment 20

11 years ago
checked in on trunk only.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 21

11 years ago
Comment on attachment 214273 [details] [diff] [review]
patch

a=timr for drivers.  A simple fix for a blocker.  Excellent!
Attachment #214273 - Flags: approval1.8.0.2? → approval1.8.0.2+
(Assignee)

Comment 22

11 years ago
checked in on both branches
Keywords: fixed1.8.0.2, fixed1.8.1

Updated

11 years ago
Whiteboard: bfcache-related → bfcache-related[rft-dl]
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)
Attachment #214273 - Flags: approval-branch-1.8.1?(dbaron) → approval-branch-1.8.1+
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.

Updated

11 years ago
Flags: in-testsuite+

Comment 25

11 years ago
v 1.8.0.2/winxp/20060308
Keywords: fixed1.8.0.2 → verified1.8.0.2
Whiteboard: bfcache-related[rft-dl] → [sg:moderate] bfcache-related[rft-dl]
Group: security

Updated

10 years ago
Flags: in-testsuite+ → in-testsuite?
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)?
You need to log in before you can comment on or make changes to this bug.