Closed
Bug 495274
Opened 15 years ago
Closed 15 years ago
[FIX]CSS changes when Firebug active in Firefox 3.5
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: rcampbell, Assigned: bzbarsky)
References
()
Details
(Keywords: fixed1.9.1, Whiteboard: [firebug-p2])
Attachments
(3 files, 1 obsolete file)
1.73 MB,
image/png
|
Details | |
471 bytes,
text/html
|
Details | |
2.26 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
Browser version: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090528 Shiretoko/3.5pre ID:20090528031233 With Firebug 1.4a30 installed (http://bit.ly/fbug14a30): 1. Open the linked URL above (http://www.cbc.ca/world/story/2009/05/19/sri-lanka-tamil-tigers-velupillai-body385.html) 2. When page has finished loading, open Firebug via the status bar icon. 3. Reload the page Expected: Page should reload, unchanged Actual: Some divs on the page are rendered differently. See attachment for differences. Does not happen in Firefox 3.0 with same version of Firebug. Originally discovered after fix of bug 493968 landed.
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Reporter | ||
Updated•15 years ago
|
Component: Layout → Style System (CSS)
QA Contact: layout → style-system
Reporter | ||
Comment 1•15 years ago
|
||
http://code.google.com/p/fbug/issues/detail?id=1808 mentions a similar issue on http://flaunt.com "firebug appears to remove the descendant operator from the "#secondary > *" selector. this did not happen with firebug 1.4a and firefox 3.0.*." johnbarton replied with: "What happens if you have Firebug on, but the Console panel disabled?" I tried this and the page loaded and displayed correctly. (note, you can disable the Console panel with the small drop-down menu arrow on the Console panel's tab).
Reporter | ||
Comment 2•15 years ago
|
||
problem exists on Windows 7, Shiretoko nightlies as well.
OS: Mac OS X → All
Hardware: x86 → All
Reporter | ||
Updated•15 years ago
|
Whiteboard: [firebug-p2]
Comment 3•15 years ago
|
||
The console injection is triggered by the first JS compile; it adds elements to the page and adds script tag. I believe that a web page could perform the same operations in a top-level script loaded in the first script tag. Thus the problem would not be limited to Firebug. Since FF 3.0 does not show this, the problem is likely related to load changes as FF3.5 tries to be more aggressive. Maybe Boris knows who knows what changed in this area, particularly relation between script and style tags. Both of the examples are quite large, it would be a great help if they where boiled down. Cutting out the content that does not matter, making the content dramatically depend upon the bug (comparing 3.0 and 3.5), and trying different order of script and style loads would zero in.
Assignee | ||
Comment 4•15 years ago
|
||
Assignee | ||
Updated•15 years ago
|
Attachment #380246 -
Attachment description: Testcase → Css for testcase
Attachment #380246 -
Attachment mime type: text/csss → text/css
Assignee | ||
Comment 5•15 years ago
|
||
Attachment #380246 -
Attachment is obsolete: true
Reporter | ||
Comment 6•15 years ago
|
||
nice, that does the trick. (In reply to comment #3) > The console injection is triggered by the first JS compile; it adds elements to > the page and adds script tag. I believe that a web page could perform the same > operations in a top-level script loaded in the first script tag. Thus the > problem would not be limited to Firebug. yeah, after seeing your comment in issue 1808, I figured I'd already misclassified this bug. Boris: feel free to move this some place (more) appropriate. > Since FF 3.0 does not show this, the problem is likely related to load changes > as FF3.5 tries to be more aggressive. Maybe Boris knows who knows what changed > in this area, particularly relation between script and style tags. could we possibly fix this by moving the console injection phase of initialization or is that likely to break the rest of our world? > Both of the examples are quite large, it would be a great help if they where > boiled down. Cutting out the content that does not matter, making the content > dramatically depend upon the bug (comparing 3.0 and 3.5), and trying different > order of script and style loads would zero in. we had that problem with the previous CSS issue. I'm going to see if I can find some simpler test cases that exhibit similar problems. Neil Lee's example of http://www.mozilla.com/en-US/ also works, though it's not exactly minimal.
Comment 7•15 years ago
|
||
(In reply to comment #5) > Created an attachment (id=380247) [details] > Standalone testcase How do I know this test passes or fails?
Assignee | ||
Comment 8•15 years ago
|
||
So as far as I can tell, nsCSSSelector::Clone has just always been broken... The attached testcase shows the bug in 1.9.0.x and later. Fx2 doesn't show the bug with that testcase, but it might not be cloning the sheet in that case or something; that's back when we blocked the parser on sheets and behavior is a bit weird. I should have paid more attention to comment 1, since that in fact pinned down the exact problem...
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #380275 -
Flags: superreview?(dbaron)
Attachment #380275 -
Flags: review?(dbaron)
Assignee | ||
Comment 9•15 years ago
|
||
Oh, and to be clear, the reftest in the patch shows the problem with no Firebug in sight. The only reason Firebug matters in the original test is because Firefug gets the .cssRules, and on m-c and 1.9.1 we do a lot more sheet cloning because of speculative prefetch. That's all that happens in the "standalone testcase", by the way: the slow-loading sheet makes sure Firebug forces the unique inners on the clones before the content actually loads, so the content sees the resulting mangled selectors.
> How do I know this test passes or fails?
Sorry that wasn't clear; that testcase needs Firebug running to fail. The passing text is "A Bx"; the failing is "Ax Bx".
Assignee | ||
Updated•15 years ago
|
Summary: CSS changes when Firebug active in Firefox 3.5 → [FIX]CSS changes when Firebug active in Firefox 3.5
Attachment #380275 -
Flags: superreview?(dbaron)
Attachment #380275 -
Flags: superreview+
Attachment #380275 -
Flags: review?(dbaron)
Attachment #380275 -
Flags: review+
Comment on attachment 380275 [details] [diff] [review] Fix and testcase r+sr=dbaron, but it would be really good to add tests for this to the test_selector_in_html function in test_selectors.html so that we test this for the bulk of our selector tests
Comment 11•15 years ago
|
||
Shaver recommended we block on this for fbug compatibility if not more.
Flags: blocking1.9.1? → blocking1.9.1+
Updated•15 years ago
|
Whiteboard: [firebug-p2] → [has reviewed patch][firebug-p2]
Reporter | ||
Comment 12•15 years ago
|
||
nicely done! thanks!
Assignee | ||
Comment 13•15 years ago
|
||
Pushed http://hg.mozilla.org/mozilla-central/rev/da44a9ed6ab2 and http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6ac28508e10a Looking into adding this to test_selectors.html.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Keywords: fixed1.9.1
Resolution: --- → FIXED
Whiteboard: [has reviewed patch][firebug-p2] → [firebug-p2]
Assignee | ||
Comment 14•15 years ago
|
||
OK. The problem there is that this bug only shows up when stylesheets are loaded via <link>; there's no way to trigger it using inline style. We could add a test for that if we could tell when the <link> is done loading (bug 185236) or if we were willing to load an entire document in test_selector_in_html and wait for it to load. I filed bug 495347 on sorting out what to do there.
Blocks: 457810
Reporter | ||
Comment 15•15 years ago
|
||
and verified fixed in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090529 Shiretoko/3.5pre ID:20090529033917. Thanks for the very quick turn-around, Boris.
Status: RESOLVED → VERIFIED
Flags: wanted1.9.1?
You need to log in
before you can comment on or make changes to this bug.
Description
•