JanZerebecki added a subscriber: JanZerebecki.
JanZerebecki added a comment.
Always doing a forced reload is not the way to go. We should try to get to the
bottom of this. Perhaps: If we can detect this case, ask the user if they want
to reload.
Can't reproduce in Firefox 40.
TASK DETAIL
Fomafix added a comment.
Now I tested with Chrome and there the label kept changed.
TASK DETAIL
https://phabricator.wikimedia.org/T55466
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Fomafix
Cc: Tobi_WMDE_SW, Jonas, Bene, JeroenDeDauw, gerritbot,
Fomafix added a comment.
I still can reproduce this behavior on www.wikidata.org with Firefox 39:
- Load an item.
- Change the label.
- Load the page history.
- Use browser's back-button
- The item is shown again, but without the changed label.
TASK DETAIL
Bene added a comment.
I now tested this and I cannot reproduce this issue on test.wikidata.org. When
changing the label, clicking another link and navigating back using the
browser's back-button I see the new label as expected. Verified on Firefox 39
and Chrome 44. This is done by the bfcache
Jonas added a comment.
OK then this can be closed? Either merge or not
TASK DETAIL
https://phabricator.wikimedia.org/T55466
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jonas
Cc: Tobi_WMDE_SW, Jonas, Bene, JeroenDeDauw, gerritbot, Aklapper,
Lydia_Pintscher added a comment.
The steps Tobi listed indeed lead to the wrong behaviour. What you should see
is bar as the label in this case.
TASK DETAIL
https://phabricator.wikimedia.org/T55466
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To:
Tobi_WMDE_SW added a subscriber: Tobi_WMDE_SW.
Tobi_WMDE_SW added a comment.
@jeroendedauw @bene: I totally agree with your opinion but as @jonas pointed
out, it is actually **not** showing you the exactly same state as before. Did
you read the original bug description
Bene added a comment.
I agree with Jeroen that the usual browser experience is that with the back
button I get exactly the state of the website I've visited before. Automatic
reloading doesn't seem to be a nice and intuitive praxis.
How did the MediaViewer team fix this? I think they had a
Jonas added a subscriber: Jonas.
Jonas added a comment.
The user could confirm a reload first...
In https://phabricator.wikimedia.org/T55466#1487862, @Bene wrote:
I agree with Jeroen that the usual browser experience is that with the back
button I get exactly the state of the website I've
JeroenDeDauw added a subscriber: JeroenDeDauw.
JeroenDeDauw added a comment.
Is that not how the web is supposed to work? I certainly come across this
behaviour often enough.
TASK DETAIL
https://phabricator.wikimedia.org/T55466
EMAIL PREFERENCES
Fomafix added a comment.
I retested removing of a sitelink. It does not replayed when using the back
button.
TASK DETAIL
https://phabricator.wikimedia.org/T55466
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Fomafix
Cc: JeroenDeDauw, gerritbot,
Fomafix added a comment.
I just tested with removing a sitelink and with adding statement on an other
item. In both tests I opened the history and click on back in the browser. The
sitelink change was replayed, the statement change was not replayed. Can
someone reproduce this behavior? What is
12 matches
Mail list logo
