michael wrote:

Also blocks the reload button, which is the normal way to restore dirtied edit fields.

iano wrote:

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!)

(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? :)

michael wrote:

(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.

(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.

michael wrote:

(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.

EN.WP.ST47 wrote:

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.

mhershberger wrote:

Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734

iano wrote:

(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?

That means that the bug described in this report does not appear anymore?

iano wrote:

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.