MW1.25.1
I do not get warnings when leaving edit pages. Tested on several wikis with different skins.
See also https://www.mediawiki.org/wiki/Thread:Skin_talk:Vector/EditWarning
MW1.25.1
I do not get warnings when leaving edit pages. Tested on several wikis with different skins.
See also https://www.mediawiki.org/wiki/Thread:Skin_talk:Vector/EditWarning
Low priority? Hmm... (
Every day people lose their edits because of a faulty mouse movements
If there are more reports of such problems, please feel free to link them.
(Also feel free to look at existing open tasks with higher priorities to compare.)
I've tried but cannot reproduce.
Tested in linux with Firefox 38 and Chromium 37, logged-in and logged-out, on mw:Sandbox and en:WP:Sandbox
If I try to close the tab or the window, both give me the "Are you sure you want to leave?" browser warning.
If I log-in, and disable the userpreference for "Warn me when I leave an edit page with unsaved changes", then the browser warning is successfully disabled.
Win 7
Firefox 38.0.5
Chrone 43.0.2357.124
Opera 30.0.1835.59
The problem is in MW 1.25, Wikipedia works fine.
http://nablawiki.ru - MW 1.25.1
other wikis (including MW 1.24) accessible from the outside but addresses can only report by mail
Confirming for the public link. I made two anonymous edits on that wiki; no JS errors displayed either in the browser console.
Works with debug=true, so the module is known and working for the installation.
Maybe a server cache problem around the ResourceLoader
No, this is because user.options is not marked as a dependency for this module. I'll fix this and we should consider backporting the fix.
Change 222979 had a related patch set uploaded (by TheDJ):
editWarning: Decleare dependency on user.options
So what I'm actually seeing here, is that the mw.user.options.set with the defaults happens AFTER the mw.user.options.get for this option.
I suspect this behavior started occurring when we introduced user.defaults, it's actually the 2nd time that I have seen it now, though I don't remember where I saw it before... This is especially interesting, since the .get is inside a jQuery dom ready.
It seems that the defaults module is bottom loaded on demand by the loader, instead of top loaded as user.options is. If there is not a single module that depends on user.options, then the dependency of user.options on user.defaults is basically put last on the queue of RL (alphabetic ordering?), and user.defaults is loaded after any other bottom loaded module.
Now reported as: T104844
Change 223152 had a related patch set uploaded (by TheDJ):
editWarning: Declare dependency on user.options