359800 - 'linkedpanel' tab attribute does not work if a tabpanel is not displayed

Status: UNCONFIRMED

(Toolkit :: UI Widgets, defect)

Description

[Xavier]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0

I've a set of four tab elements in a tabs element,
with the matching 4 tabpanel elements in their tabpanels container.
Each tab element has a linkedpanel attribute set to the id of the appropriate tabpanel.

If I hide the 3rd tab AND the 3rd tabpanel (css display:none), clicking on the fourth tab won't display the fourth tabpanel.

If I hide the 3rd tab but not the matching tabpanel, then it works all right.

I know hiding the tabpanel was useless. But it should not break the linkedpanel attribute functionnality.

Reproducible: Always

Steps to Reproduce:
1. setup 4 tab elements with the linkedpanel attribute equals to the id of 4 tabpanel elements
2. hide the 3rd with a css display:none rule
3. select the 4rth tab : the 4th tabpanel does not show up.

Actual Results:  
 the 4th tabpanel does not show up.

Expected Results:  
the 4th tabpanel should show up

Comment 1

[Alex Vincent [:WeirdAl]]

This bug has been sitting UNCO for a very long time, without any testcases.

Comment 2

[Ada [:adalucinet]]

Marking as Resolved WFM per comment 1 and the lack of updates.

Comment 3

[Xavier]

Hi Alexandra.

It just took me 20 seconds to test this bug by just opening a few tabs in Firefox 22 (on windows 7), then hiding one tab and its matching panel using the Dom Inspector, and I can confirm the bug is not fixed.

Comment 4

[Alex Vincent [:WeirdAl]]

Xavier, can you reproduce this bug without using a tool like DOM Inspector to corrupt the data set the browser relies on?  Just using Firefox user interface, please.

If a user uses a tool like DOM-I or the Chrome Debugger to change several manually in order to reproduce, it should not be considered a bug because that takes a lot of effort on the user's part to shove FF into this unnatural position.  The point I'm making is that it's not a practical real-world scenario:  only someone going out of their way to cause this on their own machine would hit it.

Comment 5

[alexander :surkov (:asurkov)]

I'd say the bug makes sense, the widget API should be robust and unbreakable. If this scenario is not in use by Firefox UI then it can be picked up by extensions. However the bug is open from 2006 what means if a problem exists the people learned how to workaround it.

Comment 6

[Xavier]

Alex Vincent, I originally filed the bug because I had the issue developing a XUL extension, exactly as Alexander suggested. I'm not usually toying around with DOMI just to try and break stuff...

Alexander, I agree, but this bug might reveal an unwanted behavior with other side effects, such as trouble in timer management in non-displayed tabs, or such.

Personally I no longer care if this bug is solved or not, but if it should be closed, then it should be with a reason other than WFS or Resolved ;)