WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 4 days ago

#34811 new defect (bug)

Preview Changes adds a new ?t= to url each time

Reported by: garethhadfield Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.3.1
Component: Administration Keywords: has-patch close reporter-feedback
Focuses: Cc:

Description

Using Safari browser. When editing a page or post and you click the [Preview Changes] button it opens a new window/tab for the preview. If you close this preview window then click [Preview Changes] again you get a url that has ?t=XXXXX (you need to be quick to notice it since it immediately forwards to a different url).

The problem is that if you close that preview window and then click [Preview Changes] again then the url gets ?t=XXXXXX?t=YYYYYY and it keeps adding ?t= each time you click [Preview Changes].

The preview still works fine. But the extra ?t= appears to be unintended.

The bug is in some workaround code in wp-admin/js/post.js
The workaround targets Safari and adds '?t=' + ( new Date() ).getTime(); to the url when you click the [Preview Changes] button.

Problem occurs in a fresh install of 4.3.1 and also in 4.4-RC1-35744.

Tested in Safari 8.0.7 (10600.7.12) OS X 10.10.4 (14E46).

Video showing problem: https://youtu.be/n1XWSCf1KZQ (use HD quality and pause the video at 0:20)

Attachments (3)

34811.1.patch (531 bytes) - added by JRGould 5 years ago.
replaces any existing datestamp before appending new datestamp in preview url
34811-gb.gif (5.9 MB) - added by hellofromTonya 4 days ago.
Safari Version 14.0.2 (16610.3.7.1.9) with Gutenberg editor
34811-classic-editor.gif (5.6 MB) - added by hellofromTonya 4 days ago.
Safari Version 14.0.2 (16610.3.7.1.9) with Classic Editor

Change History (8)

#1 follow-up: @swissspidy
5 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

Can confirm this using trunk. Wonder why that workaround is needed.

#2 in reply to: ↑ 1 @ocean90
5 years ago

Replying to swissspidy:

Wonder why that workaround is needed.

See #18341.

@JRGould
5 years ago

replaces any existing datestamp before appending new datestamp in preview url

#3 @JRGould
5 years ago

  • Keywords has-patch added; needs-patch removed

#4 @swissspidy
4 years ago

  • Keywords close added

autosave.js doesn't contain the webkit fix from #18341 anymore, so it seems like this doesn't apply anymore.

edit: looks like it's in post.js now, my bad.

Last edited 4 years ago by swissspidy (previous) (diff)

@hellofromTonya
4 days ago

Safari Version 14.0.2 (16610.3.7.1.9) with Gutenberg editor

@hellofromTonya
4 days ago

Safari Version 14.0.2 (16610.3.7.1.9) with Classic Editor

#5 @hellofromTonya
4 days ago

  • Keywords reporter-feedback added

I'm not able to reproduce the problem using Safari Version 14.0.2 (16610.3.7.1.9) with Classic Editor nor Gutenberg editor (see attached gifs above) against trunk.

@garethhadfield does this issue persist today? I'll mark this ticket as a close worksforme candidate assuming that it is resolved in newer versions of Safari.

@swissspidy Do we need this WebKit workaround anymore? If no, we might want to open a new ticket to remove it.

Note: See TracTickets for help on using tickets.