New issue
Advanced search Search tips
Starred by 19 users
Status: WontFix
Closed: Sep 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Sign in to add a comment
history pushState doesn't affect :target selector
Reported by, Jul 13 2011 Back to list
Chrome Version       : 12.0.742.112
OS Version: OS X 10.6.6
URLs (if applicable) :
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

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, Jul 13 2011
Added button to remove hash via location.hash:
Labels: -OS-Mac -Area-Undefined OS-All Area-WebKit WebKit-Core
Comment 3 by, Jul 19 2011
Labels: Mstone-X
Project Member Comment 4 by, 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, Mar 10 2013
Labels: -Area-WebKit -WebKit-Core -WebKit-CSS Cr-Content Cr-Content-CSS Cr-Content-Core
Project Member Comment 9 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Project Member Comment 10 by, 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, 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
Status: Available
Owner: ----
Status: WontFix
Tested 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 (Section 7.5.2).

Comment 16 by, Jan 25 2016
Then change the spec, because this is wrong.
Comment 17 by, Feb 5 2016
Hi Chromium folks.

Over in the WebKit bug ( 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:
Status: ExternalDependency
Waiting for clarification on
Labels: -Hotlist-Interop
Labels: -Type-Bug Type-Feature
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. 
Sign in to add a comment