Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 296418 - can't put tags/elements before prefpane elements in prefwindow
: can't put tags/elements before prefpane elements in prefwindow
Status: NEW
Product: Toolkit
Classification: Components
Component: Preferences (show other bugs)
: unspecified
: x86 Windows XP
: -- major with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Neil Deakin
: 636064 (view as bug list)
Depends on:
Blocks: 295867 296606
  Show dependency treegraph
Reported: 2005-06-02 11:46 PDT by Nickolay_Ponomarev
Modified: 2014-10-04 13:44 PDT (History)
23 users (show)
asa: blocking1.8b5-
asa: blocking‑aviary1.5-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Nickolay_Ponomarev 2005-06-02 11:46:03 PDT
When you put a tag, like <script/> or <button/> inside a prefwindow, before any
prefpanes, the window breaks: when I select first pane in the selector, the
second pane is actually displayed, same when I select the second pane.

Moving the tags after the prefpanes makes Firefox happy.

Playing with the document in the DOMi makes me think it's a core bug, but I
couldn't make a testcase not using the preferences binding, so I'm filing it in
Toolkit for now.

To reproduce, open the following in a chrome window and try switching panes:
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/global.css" type="text/css"?>

<prefwindow xmlns=""
            id="options-test" title="Options" style="width: 40em;">


  <prefpane id="paneGeneral" label="1">
    <button label="1"/>

  <prefpane id="panePattern" label="2">
    <button label="2"/>

Comment 1 Mano (::mano, needinfo? for any questions; not reading general bugmail) 2005-06-04 03:03:35 PDT
This blocks a fix to bug 296606.
Comment 2 Justin Dolske [:Dolske] 2005-08-20 18:35:20 PDT
Yikes, this is a bigger problem than it looks like.

Just about every extension/example I've seen sets up a chrome window with code like:

<dialog> or <overlay>
    <script src="your extension code.js"/>
    ...bunch of XUL...

But if you do this with a <prefwindow>, things break in weird and non-obvious
ways. I just spent time banging my head against the wall because the preference
panes were in the reverse order of the tabs... Click the first tab, get the last
pane! Removing two <script> tags I had between the <prefwindow> and first
<prefpane> seems to have fixed that. I'm still getting a random tab with
incorrect pane content when the window opens, but after clicking a tab things work.

I would imagine many potential users of <prefwindow> are going to give up and
not use it with problems like this...
Comment 3 Asa Dotzler [:asa] 2005-08-22 14:16:57 PDT
we need to document this at devmo. not going to get this changed for 1.5. Deb,
can you make sure we have some kind of note on the workaround for this at devmo?
Comment 4 Deb Richardson [:dria] (plz NEEDINFO) 2005-08-23 05:29:32 PDT
Who would be the best person to write this up?  I'd recommend simply adding it
directly to the wiki.  I could start a page for it if you like, if you could
provide a title.  
Comment 5 Justin Dolske [:Dolske] 2005-08-27 10:19:45 PDT
(In reply to comment #4)
> I could start a page for it if you like, if you could
> provide a title.  

Actually, I ran across this while writing some sample code for the related
article page on the wiki... I'll add it to a tips/tricks/traps section.

Comment 6 Paul Tomlin 2006-03-09 03:20:48 PST
anyone feel like putting a link to the devmo article?
Comment 7 Andrew Williamson [:eviljeff] 2006-04-14 09:53:03 PDT
The notes on this bug seem to indicate there is a workaround but no matter in my experience no matter where you put the <script> tags it still breaks in the same way.
Comment 8 Tom Aratyn 2007-09-28 10:16:10 PDT
Just wanted to mention this is still an issue since the bug seems to have gone quiet. 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061201 Firefox/ (Ubuntu-feisty)
Comment 9 Jonas Nockert 2007-12-17 11:09:25 PST
Adding to Tom Aratyn's report, the bug still exists in
  Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20071203
  Ubuntu/7.10 (gutsy) Firefox/ (Linux Mint)

However, it works fine under OSX 10.4 in both 2.0.0.* and
  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b1)
  Gecko/2007110903 Firefox/3.0b1
Comment 10 Arivald 2007-12-31 07:04:11 PST
I spend some time to resolve this bug, because i use prefwindow in my extension.

This bug is caused by somehow incorrect code in deck implementation. It have problem with correctly handling anonymous XBL content.
Also deck binding in general.xul does not care about anonymous content (uses "childNodes" for example).
Unfortunately i work only on XUL/XBL/JS level, and "deck" seems to be implemented in C++.

Anyway i found some workaround for this problem:
 1. I changed "prefwindow" binding to use "vbox" instead of deck.
 2. In "_selectPane" method i first collapse all prefpanes, and then un-collapse active one.

As far as i can test it (TB on WinXp), it works OK.

Comment 11 benc 2008-08-18 23:54:30 PDT
Does this problem affect prefwindow's with just one prefpane? 

I wasn't sure from reading:
Comment 12 Christian Höltje 2010-01-21 18:44:37 PST
This wasn't effecting me in 3.5.6, but now it's hitting me hard in 3.6.  I don't seem to be able to put *anything* under prefwindow other than prefpane.

I'm not sure where I can put my script and stringbundleset elements, now. :-(
Comment 13 Nickolay_Ponomarev 2010-01-22 04:54:30 PST
Christian: if you can't use the workarounds that worked previously, it's a different bug from this one; you should find (or file) another bug (preferably with a testcase and the day it regressed). Or at least post to the newsgroups.
Comment 14 Christian Höltje 2010-01-22 07:00:24 PST
It turned out to be the prefwindow/@onload attribute.  When I moved it into prefpane/@onpaneload it worked.  Does that warrant a new bug?
Comment 15 Nickolay_Ponomarev 2010-01-23 10:21:28 PST
I still don't understand what your issue was and whether it was a regression since 3.5, so yes, it shouldn't be discussed here. Either in a separate bug or in a newsgroup, depending on how sure you are that it's a bug.
Comment 16 Jorge Villalobos [:jorgev] 2011-04-25 11:31:35 PDT
*** Bug 636064 has been marked as a duplicate of this bug. ***

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