Last Comment Bug 261826 - XUL tabs appear in wrong order, if a tab's HIDDEN attribute is set to TRUE then later revealed by either setting HIDDEN to FALSE or removing the HIDDEN attribute entirely.
: XUL tabs appear in wrong order, if a tab's HIDDEN attribute is set to TRUE th...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout: Misc Code (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
:
Mentors:
: 366116 (view as bug list)
Depends on: 272646 307394
Blocks: 307085
  Show dependency treegraph
 
Reported: 2004-09-27 12:25 PDT by agilmore
Modified: 2009-01-31 18:13 PST (History)
15 users (show)
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
The testcase (837 bytes, application/vnd.mozilla.xul+xml)
2004-10-01 08:12 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details
Assert fired by that testcase (1.21 KB, patch)
2004-10-01 09:35 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details | Diff | Splinter Review

Description agilmore 2004-09-27 12:25:47 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

The following XUL demonstrates the problem.  The tabs will appear in the
incorrect order : first, second, fourth, third.

<!-- XML  Start here -->
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window id="MyWindow"
	title=""
	xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
	width="800"
	height="600"
	onload="revealTab()">

<script type="application/x-javascript">
	function revealTab(){
		document.getElementById("fourthTab").setAttribute("hidden", "false");
		}
</script>

<tabbox>
	<tabs>
		<tab label="first"/>
		<tab label="second"/>
		<tab label="third"/>
		<tab id="fourthTab" label="fourth" hidden="true"/>
	</tabs>
	<tabpanels>
		<tabpanel>
			<label value="First page"/>
		</tabpanel>
		<tabpanel>
			<label value="second page"/>
		</tabpanel>
		<tabpanel>
			<label value="third page"/>
		</tabpanel>
		<tabpanel>
			<label value="fourth page"/>
		</tabpanel>
	</tabpanels>
</tabbox>
</window>
<!-- XML End -->

Reproducible: Always
Steps to Reproduce:
1. View code placed in 'Details' in mozilla browser
2. 
3.

Actual Results:  
Third tab appears after the Fourth tab, rather then where it should appear, before.

Expected Results:  
Display the tabs in the order they are defined in the XUL - First, Second,
Third, Fourth.

This bug occurs at least in FF 9.x, 1.0PR and Mozilla Navigator, on OSes Win98,
Win2000 and Debian Linux.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2004-10-01 08:12:11 PDT
Created attachment 160748 [details]
The testcase
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2004-10-01 08:58:03 PDT
Looks like frame construction gets confused about where the frame for the
tabpanel goes....

In particular, the problem is that the XBL inserts a spacer at the beginning of
the child list of the <tabs> and that in nsCSSFrameConstructor::ContentInserted
we call nsCSSFrameConstructor::FindPreviousSibling to find the previous sibling.
 But we use aIndexInContainer as the place to start looking, and our index in
the content iterator is actually one larger (because of the anonymous content
XBL inserted).

See the XXX comment before the FindPreviousSibling() call in ContentInserted();
that's biting us here, basically.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2004-10-01 09:35:50 PDT
Created attachment 160758 [details] [diff] [review]
Assert fired by that testcase
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2004-10-01 09:38:18 PDT
I think the best thing to do here would be to make GetInsertionPoint() return
not only the insertion point but also the index of the content in the insertion
point....  That would replace aIndexInContainer for the following manipulations,
then.

Alternately, we need to fix FindPreviousSibling() to not start with
aIndexInContainer, since that can end up bogus.

Thoughts?
Comment 5 Neil Deakin (away until Oct 3) 2007-01-08 07:26:52 PST
*** Bug 366116 has been marked as a duplicate of this bug. ***
Comment 6 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2007-01-08 17:39:26 PST
A hack(?) would be to wrap the tabs <children> with <hbox>, which has the added side-effect of making ordinal on <tab>s work as expected (since consumers don't have to understand the spacers on the ends of the <tabs>).  Of course, doing that causes crashes (why wouldn't it?  eXtremely Unstable Languages are the best!), so I'm not going to pursue cleaning up the theme to look right.
Comment 7 neil@parkwaycc.co.uk 2007-01-09 02:45:37 PST
(In reply to comment #6)
>A hack(?) would be to wrap the tabs <children> with <hbox>
Unfortunately this stops the tabs from flexing properly, so it's no use.
Comment 8 Nochum Sossonko [:Natch] 2009-01-29 13:16:28 PST
I'm pretty sure setting .collapsed instead should mitigate these problems (at least some of them).
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2009-01-29 17:38:21 PST
Fixed by checkin for bug 307394.  Checked in test.

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