798137 - Make @-moz-document trace reload-less URL changes (pushstate, hashchange)

Status: REOPENED

(Core :: CSS Parsing and Computation, defect, P5)

Description

[Michal Čaplygin [:myf]]

Attachment: test pages and userContent.css

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/18.0 Firefox/18.0
Build ID: 20121004030525

Steps to reproduce:

Userstyle (either native chrome/userContent.css or Stylish) using @-moz-document block matching certain URL(s).


Actual results:

Getting said URL in locationbar via pushState / replaceState methods does not trigger userstyle document location matching mechanism. Ie visiting "real" page triggers userstyle but having the same location from pushState does not. 


Expected results:

Supposedly, location matching mechanism should catch even this kind of URL.
Testcase included.

Based on report at http://forum.userstyles.org/discussion/32675/regexp-bug-or-facebook-mess

Comment 1

[Boris Zbarsky [:bzbarsky]]

We don't really want to force a full restyle on every pushstate... :(  Need to think of a way to avoid that.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Also, it should be possible to put together a standalone testcase, since web pages can use @-moz-document rules....

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 4

[Boris Zbarsky [:bzbarsky]]

Maybe we could only rebuild rule cascades for rule processors that were affected by @document rules?

Comment 5

[Michal Čaplygin [:myf]]

Attachment: interactive testcase

Changing location.hash via plain old anchor link does obviously the same.

Increasing number of webapps using either old 'hashbang' or new pushsate mechanism raises demand for this esp. in userstyles community.
---
Haven't thought before that @-moz-document is available outside user styles, thanks for letting me know :]

Comment 6

[Cameron McCormack (:heycam)]

Bug 77999 should let us avoid refreshing rule cascades if the set of matching @-moz-document rules haven't changed.  Then we can call nsPresContext::PostMediaFeatureValuesChangedEvent (assuming @-moz-document rules and media queries end up using the same mechanism in bug 77999) from nsHistory::PushOrReplaceState and other places.

Comment 7

[Cameron McCormack (:heycam)]

@-moz-document is being neutered, and just supported via the hack in bug 1446470, so I think this is WONTFIX.

Comment 8

[Michal Čaplygin [:myf]]

(In reply to Cameron McCormack (:heycam) from comment #7)
> @-moz-document is being neutered, and just supported via the hack in bug
> 1446470, so I think this is WONTFIX.

(tl;dr: does it mean @-moz-document is being nuked completely in all levels of the cascade?)

Skimmed trough provided references and although not been able to find it explicitly stated, I understand  the intention is to remove @-moz-document support in the **author** level style sheets, leaving it exclusive for user styles -- just as I thought it has been working all the time (as it turned out in bug 1035091 it probably should have) and as seen above Boris enlightened me back then, but it is not the main point of this issue.

Could you please point me to the relevant decision?  Nuking this would mean making userContent.css quite useless.

Comment 9

[Cameron McCormack (:heycam)]

Yes, sorry, I think I misinterpreted the current plan.  @-moz-document is still available in userContent.css, and the neutering is indeed only for content pages.  Which means this bug is still valid (although not a high priority one).