Page MenuHomePhabricator

Hotkeys in Safari Mac
Closed, ResolvedPublic


The Safari developers have decided to change the accesskey modifiers. This will require an additional case in wikibits.js.

The new modifier keys are ctrl-option (or ctrl-alt) and they are active in at least WebKit 527 and higher.

var match = navigator.userAgent.match(/AppleWebKit\/(\d+)/);

if (match) {
  var webKitVersion = parseInt(match[1]);
  if (webKitVersion < 420)


I'll try to make a patch for this.

Version: unspecified
Severity: minor



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:14 PM
bzimport set Reference to bz14401.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 4954
new tooltipAccessKeyPrefix'es for newer Safari versions.

This patch adds checks for applewebkit version and safari windows, allowing accurate tooltips for the accesskeys.

attachment safari-accesskeys.patch ignored as obsolete

Created attachment 4955
updated patch with fixed is_safari_win detection

I made a type. Corrected.


ayg wrote:

Did you test this patch? If so, on what versions of Safari? Also, in your patch, it seems like is_safari_win falls back to the "alt-" prefix for all versions, which is an unmentioned change from current behavior. Is this correct?

A quick behavior check to confirm the required hotkey to trigger "edit":

  • Mac/Safari 3.1: control+e

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_3; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.20

  • Mac/Webkit nightly: control+option+e

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_3; en-us) AppleWebKit/527+ (KHTML, like Gecko) Version/3.1.1 Safari/525.20

  • Win/Safari 3.1: alt+e

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, Like Gecko) Version/3.1 Safari/525.13

  • Win/Webkit nightly: alt+e

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/526+ (KHTML, like Gecko) Version/3.1 Safari/525.13

Tabs are labeled correctly with the patch; applied on r35961.

Thanks for confirming trough the tests brion. I had indeed forgotten to mention that Safari windows users were already seeing an incorrecte label from the inception of the Safari Windows version.