div is not hidden and show correctly when it contains a GfxButtonControl

VERIFIED FIXED in M14

Status

()

P3
blocker
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: rods, Assigned: attinasi)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] Fixed 2/24)

Attachments

(2 attachments)

Comment hidden (empty)
(Reporter)

Comment 1

19 years ago
making beta
Keywords: beta1
Target Milestone: M14
(Reporter)

Comment 2

19 years ago
Created attachment 5598 [details]
simple test case
(Reporter)

Comment 3

19 years ago
buttons and selects cause it to not work
radio, checkboxes and input text work fine
(Assignee)

Comment 4

19 years ago
Created attachment 5601 [details]
XUL file that originally showed the problem - for verification

Comment 5

19 years ago
Putting on PDT+ radar for beta1.  Can you give you an estimate on time needed to 
fix in the Status Summary please?  Thanks!
Whiteboard: [PDT+]
(Assignee)

Comment 6

19 years ago
So far I have seen that there is some sort of problem in resolving the style for 
the DIV AFTER the frames and style context's have been destroyed and while they 
are being recreated. The DIV's area frame is having its style resolved, but we 
find an existing style rule on one of the parent's children so we use that 
instead of creating a new one. More accurately, for the cases that fail, the 
call to FindChildWithRules inside of StyleSetImpl::GetContext is finding a child 
context, whereas in the cases that are OK there is no child context with 
matching rules. When I trace the StyleContextImpl's destruction it appears 
to be correct, so I don't understand yet why we are finding a child with 
matching rules. That's all I know so far... 

I have narrowed down the code where the symptoms appear. I'd guess it will take 
me another day to find and fix to underlying cause, so it should be closed by 
tomorrow evening.
Status: NEW → ASSIGNED
(Assignee)

Comment 7

19 years ago
Actually, buttons appear to be the only thing that makes it not work... all 
other elements I have tried work fine.

Comment 8

19 years ago
Adding Est fix date to Status Whitboard
Whiteboard: [PDT+] → [PDT+]02/23 Est fix.
(Assignee)

Comment 9

19 years ago
It is ollking like a ref-count problem on one of the style contexts for the 
input element (button). I am trying to figure out where it is occuring... 

I think it may be a problem with the parenting of the style contexts because the 
ref counts appear to be off, but additionally there is a strange child context I 
cannot yet account for that appears to be holding the lingering reference to the 
context.

I bumped the estimated time to fix by a day.
Whiteboard: [PDT+]02/23 Est fix. → [PDT+]02/24 Est fix.
(Assignee)

Comment 10

19 years ago
Additional info: if the control in the DIV is an HTML <BUTTON> it works fine. If 
it is a <SELECT> it is broken. Essentially, every case that fails involves a 
GfxButton, and if there is no GfxButton it appears to be fine...
(Assignee)

Comment 11

19 years ago
Updated the summary to reflect the latest findings...
Summary: div is not hidden and show correctly depending on what it contains → div is not hidden and show correctly when it contains a GfxButtonControl
(Assignee)

Comment 12

19 years ago
Fixed. A StyleContext was not being released and was causing the entire 
parentage to be retained and reused. I fixed it but found that pollman had 
already checked in the same fix for a seperate bug (bug 28691).
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+]02/24 Est fix. → [PDT+] Fixed 2/24

Comment 13

19 years ago
Tested with 03-08-09, and it works fine. Used provided testcase attachments to 
verify. Marking verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.