Make WordPress Core

Opened 2 years ago

Last modified 2 years ago

#54568 new defect (bug)

WordPress admin overwrite JS history.state

Reported by: maximeschoeni's profile maximeschoeni Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch
Focuses: javascript Cc:

Description

WordPress admin is injecting a piece of javascript at runtime (https://developer.wordpress.org/reference/functions/wp_admin_canonical_url/) that prevent accessing history.state. This is annoying because you cannot use history.pushState() and history.replaceState() functions properly in javascript.

Reproduce the bug:

  1. Navigate to any wp admin page and open the browser developer console
  2. Enter window.history.replaceState({name: "hello"}, null) in console
  3. Navigate to any other page
  4. Go back and enter history.state // result -> null

Problem:
The code overwrites any history.state with null value:

window.history.replaceState( null, null, document.getElementById( 'wp-admin-canonical' ).href + window.location.hash );

Solution:
Replace null value by window.history.state (which also default to null):

window.history.replaceState( window.history.state, null, document.getElementById( 'wp-admin-canonical' ).href + window.location.hash );

The fix is very easy and has no side effect.

Attachments (1)

patch.diff (656 bytes) - added by maximeschoeni 2 years ago.

Download all attachments as: .zip

Change History (5)

@maximeschoeni
2 years ago

#1 @kevin940726
2 years ago

The change makes sense to me!

#2 @adamsilverstein
2 years ago

@maximeschoeni Thanks for the bug report.

Can you describe the use case for why you want to access history.state in wp-admin?

The original code here was introduced for https://core.trac.wordpress.org/ticket/23367

#3 @maximeschoeni
2 years ago

Quite a specific thing, I needed a modal to open in a popup and the modal have different states and I thought it was nice if you can navigate between states using browser history... Actually there are different ways (probably betters) to do than storing things in history.state, but I was curious why it didn't work. I understand the purpose of this piece of javascript but I see no reason why it has to overwrite the history.state, and it rather sounds like a bug.

#4 @audrasjb
2 years ago

  • Version trunk deleted

Hello, thanks for reporting this ticket. It appears this issue wasn't introduced in WP 5.9, so I'm removing the trunk version from the ticket.

Note: See TracTickets for help on using tickets.