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: |
|
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)
Change History (8)
#1
follow-up:
↓ 2
@
5 years ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to Future Release
#4
@
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.
#5
@
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.
Can confirm this using trunk. Wonder why that workaround is needed.