69518 - dynamic changes of <br clear> no worky

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect)

Description

[Hixie (not reading bugmail)]

STEPS TO REPRODUCE
   1. Add the following style rule:
        br:before { content: ""; }
   2. Add a <br> element.
   3. Dynamically toggle the 'clear' attribute of said <br> element.

EXPECTED RESULTS
   1. Same as would happen without the style rule above, namely the new value
      of the 'clear' attribute should take effect.

ACTUAL RESULTS
   1. MapAttributesInto in nsHTMLBRElement.cpp is never called, and so the 
      reflow doesn't move the <br> element.

Note: There is a side issue here, which is that content:"" should never have any
effect _anyway_ since that is the inital value. But the bug is still present if
you add actual generated content, like "\A" or "foo".

See testcase.

Comment 1

[Hixie (not reading bugmail)]

Attachment: Self explanatory testcase based on initial description.

Comment 2

[Marc Attinasi]

I wonder if this is related to a bug that was sent to me by the editor folks
(bug 69098). In both cases, content is screwing up our dynamic reflow, but the
content model is good so we can handle it on initial reflow.

Comment 3

[Marc Attinasi]

P3 --> Moz 1.0

Comment 4

[Hixie (not reading bugmail)]

The problem is that when the attribute is changed and the style system attempts
to notify the primary frame, the frame it finds is a ':-moz-gc-wrapper-inline',
not the <br>'s main frame.

Comment 5

[Hixie (not reading bugmail)]

In fact I just noticed this is in the console:

frame: Inline(br)(3) (04D02374) style: 04D023CC :before {}
Wrong parent style context:  style: 04D02E14 {}
should be using:  style: 04D03024 :-moz-gc-wrapper-inline {}

Comment 6

[Hixie (not reading bugmail)]

So... apparently that _is_ the primary frame. The problem is its not the special-
BR-frame-that-supports-'clear'-even-though-it's-an-inlinish-element frame. It
appears that the <br> frame is not being informed that it has changed.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Why (and how) would a frame be "informed" that it has changed?

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(It's also worth noting that, at least in current builds, br:before isn't needed
to see the bug.)

Comment 9

[Hixie (not reading bugmail)]

I have no idea why or how a frame would be notified, I was just assuming that
since we have to send an event/reflow/whatever to a frame when a mapped
attribute is changed, the frame that has the event/is reflown/whatever ought to
be the one that will be affected by said attribute. I'm just guessing, though.

The fact that the :before pseudo is no longer necessary is interesting, though,
and makes this a regression. It also means that this no longer blocks the bug
that reimplements <br> using :before (bug 38370), since it only blocked it
because I was worried it would be a regression. :-)

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 108665 has been marked as a duplicate of this bug. ***

Comment 11

[Eli Friedman]

Testcase is working in FF 2.0 and trunk; marking WORKSFORME.