68198 - Need to finish reresolution filtering for attribute change

Status: RESOLVED DUPLICATE of bug 163556

(Core :: CSS Parsing and Computation, defect)

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Adding on top of the work in 38378 to track which elements/classes/ids care
about a given attribute's value for their style settings will let us win more,
perhaps even to the levels of 68103's brutal hack.

Also, making it work for HTML attribute changes will help some.

And while you're in there, waterson, can you remove my nsHashtable blasphemy?
There's a dear.

Comment 1

[David Hyatt]

Don't forget to observe namespaces (HTML vs. XUL namespace) as well.

Comment 2

[rbs]

Possible room for generalization and fine-tuning?

Chris Waterson wrote in message news:[e-mail]...
> Marc Attinasi wrote:
> >
> > I'm confused... If we have style rules that use the 'value' attribute,
> > then how did we come to think that we could just ignore changes to the
> > attribute? Is the use of the 'value' attribute in a selector somehow
wrong?
>
> I think shaver suggests that
>
>   foo[value="bar"] { ... }
>
> should not re-resolve style in this case:
>
>   <bappy id="blah" value="blop">
>   <script>
>   document.getElementById("blah").setAttribute("value", "blorg");
>   </script>
>
> because `bappy' is not a `foo'.

dosn't this apply to more then attribute changes? what about tracking which
elements have :hover rules?
In other words:

foo:hover { ... }

shouldn't re-resolve style when hovering a <bar> element.

/ Jonas Sicking

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Attachment: mildly frightening diagnostic patch

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

The attached patch will console-spew entries like:

  ||+ <option -moz-option-selected>||

for each SetAttribute that results in a style reresolution.  Just add yourself
to the lucky list at the top.

Opening a bugzilla page is a huge mess of those, in fact.  And we spend a lot of
time, when bringing up the first window with about:blank, making DAMNED SURE
that the (never seen) scrollbar is collapsed.

Comment 5

[rbs]

What seems to make this bug stagnant is to come-up with a taxynomy of the HTML
attributes and their effects -- in a similar way like that of the CSS properties: 
http://lxr.mozilla.org/seamonkey/source/content/shared/public/nsCSSPropList.h

Comment 6

[rbs]

An alternative is to come up with the taxynomy of attributes/pseudo-elements
that don't affect style -- whichever is easier...

Comment 7

[Marc Attinasi]

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

Comment 8

[rbs]

List of HTML attributes: http://www.w3.org/TR/REC-html40/index/attributes.html

Comment 9

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 10

[Boris Zbarsky [:bzbarsky]]

So... The goal here is to not spend more time checking whether a reresolve is
needed than it takes to just do a reresolve...

Right now we check whether the relevant attr has rules matching it.  I suppose
we could hash on attr name/namespace and content localname/namespace instead of
just hashing on the attr....  Would that be worth trying?  That should not slow
things down too much....

Comment 11

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

I think much of this was done in bug 163556 and any need for anything else was blown away by the yet-more-powerful optimizations in bug 523294.