[go: up one dir, main page]

Page MenuHomePhabricator

Random "Confirm before you leave" alerts when browsing Wikimedia Commons.
Closed, ResolvedPublicBUG REPORT

Description

There appears to be a race condition of sorts. I can reproduce it within a minute or so of clicking around but I've not found a consistent pattern.

  1. https://commons.wikimedia.org/w/index.php?title=File:AS12-47-6987_(21659597215).jpg&diff=next&oldid=529987348
  2. Go "next diff" a few times.
  3. Go "previous diff" a few times.
  4. Repeat.

Actual result:

For no apparent reason, the wiki is preventing me from navigating elsewhere, on the incorrect assumption that some edit or other input has been entered by me and that I would lose that by navigating away.

Screenshot 2022-07-06 at 17.11.19.png (1×1 px, 496 KB)

To try and attribute the issue to something, I looked at the following state from the console:

//> $('textarea')
Object { length: 0 }
//> window.onbeforeunload+''

"function(){var allPanels,
hasChanges;allPanels=Object.keys(statementPanels).map(function(propertyId){return statementPanels[propertyId];}).concat(captionsPanel);hasChanges=allPanels.some(function(panel){return panel&&panel.isEditable()&&panel.hasChanges();});if(hasChanges){return mw.msg('wikibasemediainfo-filepage-cancel-confirm');}}"

It seems WikibaseMediaInfo is a likely suspect here.

Event Timeline

The issue is reliably reproducible on commons wiki wmf.19 on files with ~ 10 revisions; click repeatedly on the "Older edit" or "Newer edit".

Screen Shot 2022-07-18 at 4.24.22 PM.png (934×2 px, 434 KB)

Note:

  • The issue seems to be specific to commons wiki: I was not able to reproduce the issue on diffs on lang wikis
Tacsipacsi changed the subtype of this task from "Task" to "Bug Report".Dec 29 2022, 10:39 AM
Tacsipacsi subscribed.

See this comment about attempts to debug this.

While the UX implication is most important here, there is an interesting performance angle as well for those browsing Commons - namely that pageviews for File description pages may be marked uncacheable in people's browsers, thus they don't enjoy the benefit of the bf-cache when navigating around.

https://calendar.perfplanet.com/2022/fast-is-good-instant-is-better/

Hi @CBogen , is there any way we can provide more information and support to help SDE prioritize this task? :)

Hi @CBogen , is there any way we can provide more information and support to help SDE prioritize this task? :)

Hi Larissa, we are not able to prioritize this task right now due to some strict deadlines and other priorities. We will reconsider for next FY.

wikibase.mediainfo.filePageDisplay

Not 100% sure this is it (but i think it is). I too noticed that when i got this warning, when i afterwards switched to the commons data view that one of the properties was in a half completed loading state, where an editor was open. Then it finished loading and the editor was no longer in the editor state.

Change 1008058 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/WikibaseMediaInfo@master] Unsure mediainfo is fully loaded before handling events

https://gerrit.wikimedia.org/r/1008058

I've made a quickfix patch, but am honestly slightly inclined to simply remove the entire beforeunload handler, as the whole mediainfo editor would have to be rewritten to make proper use of onbeforeunload.

Change 1008058 merged by jenkins-bot:

[mediawiki/extensions/WikibaseMediaInfo@master] Remove onbeforunload handler

https://gerrit.wikimedia.org/r/1008058

Checked in commons beta and commons wmf.22 - the issue is not present anymore. Any more work needs to be done here? if not, then the task could be marked as Resolved.

Krinkle assigned this task to TheDJ.
Krinkle triaged this task as High priority.

Thanks!

Created a follow up task, because several people implied that they would still appreciate a working version of this.