Closed Bug 307088 Opened 19 years ago Closed 5 years ago

tab not responding if append to parent with hidden attribute

Categories

(Core :: XBL, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jooaun.saw, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(2 files)

2.31 KB, application/vnd.mozilla.xul+xml
Details
2.20 KB, application/vnd.mozilla.xul+xml
Details
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5

Tab does not respond to clicks, so not able to switch tabs.

Reproducible: Always

Steps to Reproduce:
1. Set parent hidden attribute to true.
2. Append tabbox with tabs to parent element.
3. Set parent hidden attribute to false.

Actual Results:  
tab does not respond to mouse clicks.

Expected Results:  
Tab should respond to mouse clicks, and switch tab. If programmer not allowed to
append element to a hidden element, should throw exception.
Attached file test case
I think this probably suffers from bug 233639.
And possibly also from bug 266590.
Hmm, actually this might depend on bug 307098.
And possibly also from bug 266590.
Assignee: jag → general
Component: XP Toolkit/Widgets → XBL
Depends on: 307098
Keywords: testcase
QA Contact: jrgmorrison → ian
Testcase2 from bug 307085 also suffers from this bug, and that testcase doesn't
use any hidden=true, so I guess this could have nothing to do with bug 307098.
I get a js error, by the way, when clicking on any of the tabs:
Error: uncaught exception: Permission denied to create wrapper for object of
class UnnamedClass
No longer depends on: 307098
Does this start working if you clone an existing (empty?) tabbox instead of
creating a new one with createElement?
Attached file testcase2
(In reply to comment #5)
> Does this start working if you clone an existing (empty?) tabbox instead of
> creating a new one with createElement?
No.
I believe this bug to cover the same issue as bug 209701. Unlike this bug,
however, bug 209701 has at least an attempt at a patch. I am therefore resolving
this bug as a duplicate of bug 209701. Feel free to reopen if you disagree.

*** This bug has been marked as a duplicate of 209701 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
I see nothing here suggesting this is related to bug 209701.  What made you think it is?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
The error message was identical when I looked.  Also, both cases involved remote XUL, which is known to have some difficulties in the XUL widget accessing some of its XBL-ized properties.
Ah, I see what the problem is.  Setting selectedIndex to 0 does nothing since  that node doesn't have an XBL binding (see bug 265086 and the fact that we apply bindings on frame construction).  Then when you click nothing is selected, and tabbox can't deal with that.

You could fix this by cloning the tabs element, I guess...
Status: UNCONFIRMED → NEW
Depends on: 265086
Ever confirmed: true
And the error message in this case comes when tabbox sees nothing is selected and tries to throw Components.results.NS_ERROR_FAILURE.  Wrapping _that_ is what fails (due to bug 209701).  But by that point it's way too late anyway -- we're already throwing.
Assignee: xbl → nobody
QA Contact: ian → xbl

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.

Status: NEW → RESOLVED
Closed: 19 years ago5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.