Closed Bug 718340 Opened 13 years ago Closed 13 years ago

Don't traverse black windows

Categories

(Core :: DOM: Core & HTML, defect)

12 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: smaug, Assigned: smaug)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Attached patch patch (deleted) — Splinter Review
There are cases when window is still black, but document isn't in CC generation. I think this would be the fix for jst's Google Reader problem. I'd like to land this small patch separately so that possible regressions are easier to find.
Attachment #588779 - Flags: review?(jst)
Attachment #588779 - Flags: review?(continuation)
The patch has been part of my bigger patch for ~two weeks now, and so far everything looks ok.
Comment on attachment 588779 [details] [diff] [review] patch Makes sense. The wrapper will always keep the window alive, so this makes sense to me. Just out of curiousity, have you looked at doing this for nsGenericElements with wrappers?
Attachment #588779 - Flags: review?(continuation) → review+
Blocks: 716598
OS: Linux → All
Hardware: x86_64 → All
Yes, nodes do check blackness already. It is just that any changes to window's CC handling *may* have more dramatic effects than changing just node/element/document handling - that is why I want to land this small patch separately.
Attachment #588779 - Flags: review?(jst) → review+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Olli Pettay [:smaug] from comment #5) > Some unknown orange. filed bug 716598 er, bug 718411
I haven't seen the error on tryserver. Is it required to traverse timeouts even when the window is black. But if so, why not when the document is in cc generation.
I don't understand it. Timeouts should be traversed anyway, since they are stored in mJSHolders and XPConnect should add that stuff to CC.
Have you tried turning on CC logging and seeing what they look like with and without this turned optimization?
Well, there is certainly a bug in videocontrols.xml. But no, I haven't checked the CC logs, since I can't reproduce the problem.
And looks like the failure isn't caused by this. It happened even after backout.
Well, at least that means we still probably understand what is happening.
https://hg.mozilla.org/mozilla-central/rev/0e7d183d0d12 The problem ended up being a regression from another patch which landed just before this one. Hopefully better luck this time.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: