New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 20 users

Issue metadata

Status: WontFix
Owner:
Not on Chrome anymore
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature



Sign in to add a comment

history pushState doesn't affect :target selector

Reported by remysh...@gmail.com, Jul 13 2011 Back to list

Issue description

Chrome Version       : 12.0.742.112
OS Version: OS X 10.6.6
URLs (if applicable) : http://jsbin.com/esunoh/
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: FAIL
  Firefox 5.x: FAIL

What steps will reproduce the problem?
1. click "select two"
2. hash on url changes
3. click button to remove hash from url
4. :target selector is still active

What is the expected result?

Should remove the :target selector as the hash is no longer on the url

What happens instead?

Doesn't update the selector.  However, if you try location.hash = ''; on the command line, it will remove the :target selector - therefore I'd expect the pushState to work the same.


Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_6) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30



 

Comment 1 by remysh...@gmail.com, Jul 13 2011

Added button to remove hash via location.hash: http://jsbin.com/esunoh/2/
Cc: darin@chromium.org
Labels: -OS-Mac -Area-Undefined OS-All Area-WebKit WebKit-Core

Comment 3 by kareng@google.com, Jul 19 2011

Labels: Mstone-X
Project Member

Comment 4 by bugdroid1@chromium.org, Aug 10 2012

Status: IceBox
Closing old bug as obsolete. Please file a new bug (with details) if this problem is still occurring for you.
Status: Unconfirmed
Not obsolete. Same issue. Is this closed?
Labels: WebKit-CSS
It's open now.
Project Member

Comment 8 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -WebKit-Core -WebKit-CSS Cr-Content Cr-Content-CSS Cr-Content-Core
Project Member

Comment 9 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 10 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-CSS Cr-Blink-CSS

Comment 11 by Deleted ...@, Jul 2 2013

Certainly not obsolete, still a problem (FF too). Can this be openend?

Comment 12 Deleted

Comment 13 by prom...@gmail.com, Jan 12 2014

I'm having similar issues as well. For me, :target is ignored when using history.pushState, but it works with forward/back buttons (even if such are popstates).
Labels: -Mstone-X -Cr-Content-Core -Cr-Blink
Owner: dstockwell@chromium.org
Status: Available
Owner: ----
Status: WontFix
Tested http://output.jsbin.com/esunoh/2/ on Windows 7:

Chrome 43.0.2357.130: pushState NO UPDATE, location.hash UPDATE
Firefox 39: pushState NO UPDATE, location.hash UPDATE
IE 11: pushState NO UPDATE, location.hash UPDATE

So the tested browsers behave compatibly.

This behaviour is per spec as it says "Since this is neither a navigation of the browsing context nor a history traversal, it does not cause a hashchange event to be fired." See https://html.spec.whatwg.org/multipage/browsers.html#dom-history-pushstate (Section 7.5.2).

Comment 16 by prom...@gmail.com, Jan 25 2016

Then change the spec, because this is wrong.

Comment 17 by beid...@gmail.com, Feb 5 2016

Hi Chromium folks.

Over in the WebKit bug (https://bugs.webkit.org/show_bug.cgi?id=83490) we've established that this has nothing to do with the hashChange event, and that the requested behavior does seem to be correct.

But literally no browser does this for now.

Would y'all be willing to revisit making the change?
Labels: Hotlist-Interop
Status: Untriaged
Status: Available
People, we're all in agreement that the current behavior is stupid right?

I've commented on the WHATWG ticket (1) suggesting we might be able to ascertain that this would be a safe breaking change (2) suggesting backwards-compatible fixes: https://github.com/whatwg/html/issues/639#issuecomment-209189744
Status: ExternalDependency
Waiting for clarification on https://github.com/whatwg/html/issues/639#issuecomment-209189744
Labels: -Hotlist-Interop
Labels: -Type-Bug Type-Feature
Owner: nainar@chromium.org
Status: WontFix
Closing this bug since there is no discussion on the ticket specified in Comment 21. Please comment here if there is progress on this ticket and we will reevaluate. 
The CSS Selectors 4 spec now says:

“Note: The current URL of a page can change as a result of user actions such as activating a link targetting a different fragment within the same page; or by use of the pushState API; as well as by the more obvious actions of navigating to a different page or following a redirect (which could be initiated by protocols such as HTTP, markup instructions such as <meta http-equiv="...">, or scripting instructions ). UAs must ensure that :local-link, as well as the ‘:target’ and ‘:target-within’ pseudo-classes below, respond correctly to all such changes in state.”

Link: https://www.w3.org/TR/selectors-4/#the-local-link-pseudo
@darin, I guess this issue needs to be ReOpen.

Sign in to add a comment