md5 wrote:

I also changed the check to be more readable:

if (a && !(isEditOrSubmit && (id == 'ca-watch' || id == 'ca-unwatch')))

The old version seems a little inverted and hard to understand.

Searching for action=edit or action=submit in the URL is *extremely* unreliable,
as the URL doesn't necessarily contain those (POST requests, $wgActionUrls, etc).

If some code relies on these it is buggy and must be removed or fixed.

md5 wrote:

I was actually thinking the same thing. In this case, it would probably be good
to use wgIsArticle==false instead, but I haven't tested it.

That assumes that ca-watch and ca-unwatch should only have their accesskey
settings ignored when wgIsArticle is false, which seems like a safe assumption
as those tabs are only added to pages that can be edited and in the case that an
edit is in progress wgIsArticle is false.

I'm not sure why this code exists to begin with...

Either the tabs are *present* or they're *not present*. If they're present, make
sure their tooltips are set right. If they're not present, don't mess with them.

I don't see any requirement for such a check.

md5 wrote:

I think the idea was that the accessKey conflicts with the one used for the
checkbox when in editing mode. But I'm not certain either.

ayg wrote:

(In reply to comment #5)

I think the idea was that the accessKey conflicts with the one used for the
checkbox when in editing mode. But I'm not certain either.

That's correct.

In that case the sensible thing is probably to check for the existence of the
checkbox, rather than trying to guess that it _might_ be present based on
aura/phase of the moon. ;)

It should be easy to identify by its id:
<input tabindex='4' type='checkbox' name='wpWatchthis' checked='checked'
accesskey="w" id='wpWatchthis' />

ayg wrote:

D'oh. Good point. Fixed in r19223.