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.
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.
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.
The issue is reliably reproducible on commons wiki wmf.19 on files with ~ 10 revisions; click repeatedly on the "Older edit" or "Newer edit".
Note:
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? :)
In T312315#8529017 , @larissagaulia wrote: 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
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.
Thanks!
Created a follow up task, because several people implied that they would still appreciate a working version of this.