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)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jooaun.saw, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(2 files)
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.
Reporter | ||
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
I think this probably suffers from bug 233639.
And possibly also from bug 266590.
Comment 3•19 years ago
|
||
Hmm, actually this might depend on bug 307098.
And possibly also from bug 266590.
Comment 4•19 years ago
|
||
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
Comment 5•19 years ago
|
||
Does this start working if you clone an existing (empty?) tabbox instead of
creating a new one with createElement?
Comment 6•19 years ago
|
||
(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.
Comment 7•19 years ago
|
||
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
Comment 8•19 years ago
|
||
I see nothing here suggesting this is related to bug 209701. What made you think it is?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 9•19 years ago
|
||
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.
Comment 10•19 years ago
|
||
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...
Comment 11•19 years ago
|
||
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.
Updated•15 years ago
|
Assignee: xbl → nobody
QA Contact: ian → xbl
Comment 12•5 years ago
|
||
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 ago → 5 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•