border-width:0 interferes with inheritance of border-style

RESOLVED FIXED in mozilla14

Status

()

Core
CSS Parsing and Computation
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Jesse Ruderman, Assigned: bz)

Tracking

(Blocks: 2 bugs, {testcase})

Trunk
mozilla14
x86_64
Mac OS X
testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

5 years ago
Created attachment 601539 [details]
testcase (dynamic)
(Reporter)

Comment 1

5 years ago
Created attachment 601540 [details]
reference (static)
The actual nsStyleBorder for the <body> ends up correct.  What's not correct is the thing stored in UsedBorderProperty()....
Oh, this is fun.

So for the <html> the computed border width does not change.  It's 0px both before and after.  Therefore for the <html> there is no reflow hint.

But nsStyleBorder returns false for ForceCompare(), so when we recompute the border for the <body> we skip comparing the old and new values, since mRuleNode is the same as before.  We thus don't notice that _its_ computed border has changed, don't trigger a reflow of the body, and thus don't update its used border.

I believe, per the documentation for ForceCompare(), that it should return true for nsStyleBorder.
Created attachment 601630 [details] [diff] [review]
Computed border on our descendants can change due to a change of our specified border width or styles even if our computed border did not change.
Attachment #601630 - Flags: review?(dbaron)
Assignee: nobody → bzbarsky
Whiteboard: [need review]
Created attachment 601631 [details] [diff] [review]
Computed border on our descendants can change due to a change of our specified border styles even if our computed border did not change.
Attachment #601631 - Flags: review?(dbaron)
Attachment #601630 - Attachment is obsolete: true
Attachment #601630 - Flags: review?(dbaron)
Comment on attachment 601631 [details] [diff] [review]
Computed border on our descendants can change due to a change of our specified border styles even if our computed border did not change.

r=dbaron.  Sorry for the delay.  (I managed to discover this too, in bug 741012; there may be some other issues there we need to fix.)
Attachment #601631 - Flags: review?(dbaron) → review+
http://hg.mozilla.org/mozilla-central/rev/55ddaad4f602
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla14
Er, https://hg.mozilla.org/integration/mozilla-inbound/rev/55ddaad4f602
https://hg.mozilla.org/mozilla-central/rev/55ddaad4f602
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Created attachment 659157 [details] [diff] [review]
Refix  in the new setup for forcing comparison in nsStyleContext::CalcDifference, since we can no longer rely on nsStyleBorder::ForceCompare.  (Bug 779968, patch 5)
Attachment #659157 - Flags: review?(bzbarsky)
Comment on attachment 659157 [details] [diff] [review]
Refix  in the new setup for forcing comparison in nsStyleContext::CalcDifference, since we can no longer rely on nsStyleBorder::ForceCompare.  (Bug 779968, patch 5)

Aargh, hg bzexport put this on the wrong bug.
Attachment #659157 - Attachment is obsolete: true
Attachment #659157 - Flags: review?(bzbarsky)
https://hg.mozilla.org/mozilla-central/rev/309d87857ce0
You need to log in before you can comment on or make changes to this bug.