history pushState doesn't affect :target selector

REOPENED
Unassigned

Status

()

defect
REOPENED
3 years ago
2 years ago

People

(Reporter: archil, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
This bug is reported by Paul Irish at:
* Webkit - https://bugs.webkit.org/show_bug.cgi?id=83490
* Chromium - http://code.google.com/p/chromium/issues/detail?id=89165

Steps to reproduce:
0. open http://jsbin.com/esunoh/2/
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 = ''; button, it will remove the :target selector - therefore I'd expect the pushState to work the same.

Updated

3 years ago
Component: General → Untriaged
Product: Firefox → Core

Updated

3 years ago
Component: Untriaged → DOM
Well, there isn't any load event either if you push non-fragment state, yet documentURI changes.
pushState is a bit odd API, but so is all of history.*.

Given that browsers work consistently here, making a change would be very regression risky.
We should probably change the spec to clarify that no :target handling should happen in this case.
Component: DOM → Document Navigation

Comment 3

3 years ago
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
I agree we should just fix this.

The fix presumably means adding more calls to EventStateManager::SetContentState(..., NS_EVENT_STATE_URLTARGET) like the ones in PresShell::GoToAnchor.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 6

2 years ago
Well, these days filing a bug here is like making a note in Evernote or whatever online service. It won't ever get fixed. So you're probably better without open bugs. I'm closing this.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX

Comment 7

2 years ago
What! This hasn't been fixed, and there's been (mild) positive interest in fixing it from this and the other browser engines, and I found a workaround: https://github.com/whatwg/html/issues/639#issuecomment-213084467

I think this should remain open, there's no reason this can't still be fixed
This is still a bug that needs to be fixed.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
You need to log in before you can comment on or make changes to this bug.