Last modified: 2013-10-30 13:15:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T25675, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23675 - Back-button script blocks normal browser behaviour
Back-button script blocks normal browser behaviour
Status: NEW
Product: MediaWiki
Classification: Unclassified
Search (Other open bugs)
1.22.0
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-27 04:02 UTC by Michael Zajac
Modified: 2013-10-30 13:15 UTC (History)
7 users (show)

See Also:
Web browser: Apple Safari
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Michael Zajac 2010-05-27 04:02:49 UTC
I routinely edit, preview, and use the back button to check where I've been. My browser (Safari 4.0.5/Mac) saves the state, including text entered in the Subject/headline and edit field. It also warns me, when necessary, that I may lose entered text, as when closing a window or tab.

Vector overrides this behaviour by trapping the back button with a modal dialogue box (blocking access to ''all'' browser windows and tabs), providing an erroneous and unnecessary error message.

> Are you sure you want to leave this page?
> 
> Leaving this page may cause you to lose any changes you have made.
> If you are logged in, you can disable this warning in the "Editing" section of your preferences.
> 
> Click OK to continue, or Cancel to stay on this page

I don't want to blanket disable this warning, if it is useful in some browsers which I may use at some times. But it is worse than useless in my main browser, Safari, so please don't throw it up in Safari.
Comment 1 Michael Zajac 2010-05-27 04:07:13 UTC
Also blocks the reload button, which is the normal way to restore dirtied edit fields.
Comment 2 Ian Osgood 2011-03-01 19:54:37 UTC
I have a different set of symptoms on the same platform (en.wikipedia.org, Safari 5, Vector skin) perhaps caused by the same script:

1. On any page, enter a search term and go to that page.
2. Use a keyboard shortcut to go back to the previous page (command-left-arrow or command-[ )
3. The page comes up with the search box empty, but with focus.
4. BUG: Within a tenth of a second, the search box fills in with the previously entered search term, and you are sent back to that page!

The bug also happens on other Wikipediae  (e.g. de.wikipedia.org)
The bug does not occur in Firefox 3.6.13.
The bug does not occur if you use the menu (History > Back) or the toolbar button.
The bug does not occur if you use a different skin, like Monobook.
The bug is not affected by the "Disable access keys" Wikipedia preference.
The bug is not affected by the "Disable AJAX suggestions" or "Enable enhanced search suggestions" preferences.

If within that tenth-of-a-second in step 4 above, I manage to click on the page body, to remove the focus from the search box.  Then the *next* time I go to the previous page, Safari will remain on the page; the bug appears to require focus to be in the search box.

If within that tenth-of-a-second, I instead clear the search box, then I am taken to the generic search page: (http://en.wikipedia.org/w/index.php?title=Special%3ASearch&search=)

These symptoms are extremely annoying, smack in the middle of my normal Wikipedia workflow, so I am upvoting the bug to "major".  (The popup dialog in the original bug is even more annoying, but at least I could disable it!)
Comment 3 Roan Kattouw 2011-03-01 20:04:46 UTC
(In reply to comment #1)
> Also blocks the reload button, which is the normal way to restore dirtied edit
> fields.
In that case the warning is spot on, then, isn't it? :)
Comment 4 Michael Zajac 2011-05-23 23:41:26 UTC
(In reply to comment #3)
> (In reply to comment #1)
> > Also blocks the reload button, which is the normal way to restore dirtied edit
> > fields.
> In that case the warning is spot on, then, isn't it? :)

It is redundant in this situation too, since the browser has a better dialogue providing the same function.

WikiMedia dialogue is a modal pop-up, blocking ALL browser windows. Safari's dialogue is a sheet, blocking only other tabs in the same window.

WikiMedia's text:

> * http://en.wikipedia.org *
> 
> Are you sure you want to leave this page?
> 
> Leaving this page may cause you to lose any changes you have made.
> If you are logged in, you can disable this warning in the "Editing" section of your preferences.
> 
> Click OK to leave this page, or Cancel to stay on this page.

Buttons: (Cancel) ((OK))

The bold heading is unhelpful. The text is incorrect: I am not leaving the page when I reload it. The dialogue is wordy, requiring reading three paragraphs to determine the appropriate action. The button text is not an action, so the reading is necessary.

The preference is global, so that I can't have WikiMedia's warning in browsers where I might consider it useful, but turn it off where it is clearly unhelpful to have. 

Safari Text:

> * Are you sure you want to reload this page? *
> 
> You have entered text on “Editing Thor (section) - Wikipedia, the free encyclopedia”. If you reload the page, your changes will be lost. Do you want to reload the page anyway?

Buttons: (Cancel) ((Reload))

The bold text makes the decision clear at a glance, and so do the action buttons. A single paragraph explains in detail.


Why is a website trying to add functionality to a browser, in the first place, and why is it overriding the way my browser already provides this function? It doesn't do it as well, and it makes it worse still because the behaviour is non-standard and unfamiliar.
Comment 5 Roan Kattouw 2011-05-24 15:46:02 UTC
(In reply to comment #4)
> WikiMedia dialogue is a modal pop-up, blocking ALL browser windows. Safari's
> dialogue is a sheet, blocking only other tabs in the same window.
> 
> WikiMedia's text:
> 
> > * http://en.wikipedia.org 
> > 
> > Are you sure you want to leave this page?
> > 
> > Leaving this page may cause you to lose any changes you have made.
> > If you are logged in, you can disable this warning in the "Editing" section of your preferences.
> > 
> > Click OK to leave this page, or Cancel to stay on this page.
> 
> Buttons: (Cancel) ((OK))
> 
> The bold heading is unhelpful. The text is incorrect: I am not leaving the page
> when I reload it. The dialogue is wordy, requiring reading three paragraphs to
> determine the appropriate action. The button text is not an action, so the
> reading is necessary.
> 
Only the middle paragraph is provided by MediaWiki. Everything else is done by your browser through the onbeforeunload event.

> Why is a website trying to add functionality to a browser, in the first place,
> and why is it overriding the way my browser already provides this function? It
> doesn't do it as well, and it makes it worse still because the behaviour is
> non-standard and unfamiliar.
Does Safari show this warning on leaving the page as well as refreshing it? I don't believe that the difference between reloading and leaving, or the fact that the browser does its own dialog thingy, is detectable by JavaScript.
Comment 6 Michael Zajac 2011-05-24 16:28:41 UTC
(In reply to comment #5)

> Only the middle paragraph is provided by MediaWiki. Everything else is done by
> your browser through the onbeforeunload event.


> Does Safari show this warning on leaving the page as well as refreshing it? I
> don't believe that the difference between reloading and leaving, or the fact
> that the browser does its own dialog thingy, is detectable by JavaScript.

Yes, I realize that these limitations apply to using HTML+CSS+Javascript to improve on web browsers' native functionality. 

So we may have to resort to browser sniffing to try restrict this added feature to situations where it's not already present.  Certainly we should stop trying to override Safari's native capability. 

Should a website be trying to modify a browser's standard behaviour at all? If your browser lacks text-editing safeguards, then switch to a better browser or build an extension to improve it. But WikiMedia shouldn't be adding “new features” that hamper the way my chosen browser already works.
Comment 7 Dan Collins 2011-07-09 02:24:57 UTC
Changing platform to All/All and web browser to Apple Safari, fixes that have been suggested include disabling the warnings for Safari only or for all browsers, but since most discussion has been around Safari I'll leave it at that.
Comment 8 Bugmeister Bot 2011-08-19 19:12:51 UTC
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
Comment 9 Ian Osgood 2012-10-24 19:44:38 UTC
(In reply to comment #2)

FYI, this problem with keyboard shortcuts for "Previous Page" on Safari (now 5.1.7) remained a problem on en.wikipedia.org until sometime within the last few weeks.  Now it works as expected!  Was there an update to Wikipedia's MediaWiki or the Vector scripts within that timeframe?
Comment 10 Andre Klapper 2012-10-25 17:55:51 UTC
That means that the bug described in this report does not appear anymore?
Comment 11 Ian Osgood 2013-10-02 15:28:05 UTC
Ugh, the bug is still there.  In my flailing around a year ago, I finally got the bug to go away by checking Preferences > Search > Display Options > Disable search suggestions.  I forgot that that setting had changed when I made my last comment.

When I uncheck that setting (i.e. reset to default prefs), I still get the behavior as described before. I am now on OS X 10.7.5, Safari 6.0.5, still using the Vector skin, tested on en.wikipedia.org.  Also, get same behavior whether or not "Enable simplified search bar" is enabled.  To be explicit, all testing has been done with default prefs if not otherwise indicated.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links