1278098 - [e10s] Ctrl+Shift+P not captured by JS on GitHub, opens a new private window

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Borek Bernard]

When writing a comment on GitHub, `Ctrl+Shift+P` switches between writing mode and preview. When I enabled Electrolysis on my Firefox 47 beta, this keyboard shortcut is no longer "swallowed" by JavaScript on github.com but also opens a new private window.

I'm not sure about the technical details but this started happening when I've enabled e10s.

Comment 1

[Makoto Kato [:m_kato] (fever, slow response)]

My understand, the latest won't send it by bug 1203059.  Because reserved="true" for Tools:PrivateBrowsing on browser-set.inc.  But I cannot find a bug for Firefox 47.  If 48+, it is bug 1203059.

Comment 2

[Borek Bernard]

That unfortunately fixes that in a "bad" way for me - in Firefox 48, pressing Ctrl+Shift+P on GitHub does not do the preview at all - it only opens a new private window which I do not want. As a workaround, can I disable the private window shortcut somehow?

BTW, personally, I don't see a private window so important that it should swallow this keyboard shortcut from content. But it might be just me, I understand that. The bad thing for me is that e10s breaks the user experience on GitHub.

Comment 3

[:Gijs (he/him)]

(In reply to Makoto Kato [:m_kato] from comment #1)
> My understand, the latest won't send it by bug 1203059.  Because
> reserved="true" for Tools:PrivateBrowsing on browser-set.inc.  But I cannot
> find a bug for Firefox 47.  If 48+, it is bug 1203059.

e10s has had this behaviour for longer, since bug 1074971, which explains the behaviour the reporter is seeing with e10s + 47.

(In reply to Borek Bernard from comment #2)
> That unfortunately fixes that in a "bad" way for me - in Firefox 48,
> pressing Ctrl+Shift+P on GitHub does not do the preview at all - it only
> opens a new private window which I do not want. As a workaround, can I
> disable the private window shortcut somehow?

That isn't currently possible from within the product. You can try using https://addons.mozilla.org/addon/s3menu-wizard/ to edit/disable them, I believe.

> BTW, personally, I don't see a private window so important that it should
> swallow this keyboard shortcut from content. 

The issue isn't so much with github or the 'importance' of private windows specifically, it's that there's no way for a browser to distinguish "nice" websites that happen to use shortcuts that have a default behaviour in the browser, and "evil" websites that stop you using the browser and break consistency / user expectations ("hitting <shortcut> should always do <thing>").

> But it might be just me, I
> understand that. The bad thing for me is that e10s breaks the user
> experience on GitHub.

I think the thinking behind it is that accel-t (new tab), accel-n (new window) and accel-w (close tab/window) are too important for websites to override, and so people thought that logically the same should apply to 'new private window'. However, I somewhat agree that opening private windows might be less important. Michael, can you comment?

Comment 4

[Borek Bernard]

By the way, FF 47 also has a bug with simpler keyboard shortcuts like Ctrl+I, opening the bookmarks panel instead of applying italics formatting (again, on GitHub). However, in FF 48, this seems to be fixed.

Comment 5

[Verdi [:verdi] Best to slack me]

(In reply to :Gijs Kruitbosch from comment #3)
> The issue isn't so much with github or the 'importance' of private windows
> specifically, it's that there's no way for a browser to distinguish "nice"
> websites that happen to use shortcuts that have a default behaviour in the
> browser, and "evil" websites that stop you using the browser and break
> consistency / user expectations ("hitting <shortcut> should always do
> <thing>").
> 

I agree with this. I don't think we should let github override the shortcut.

It seems like the problem is that Chrome and Safari use CTRL+Shift+N for private browsing, while we and IE use CTRL+Shift+P (Edge doesn't have a shortcut) and Github must of felt that it was ok to have their shortcut only work in Chrome and Safari. I guess the question is do we want to change our shortcut for private browsing?

Comment 6

[:Gijs (he/him)]

(In reply to Verdi [:verdi] from comment #5)
> (In reply to :Gijs Kruitbosch from comment #3)
> > The issue isn't so much with github or the 'importance' of private windows
> > specifically, it's that there's no way for a browser to distinguish "nice"
> > websites that happen to use shortcuts that have a default behaviour in the
> > browser, and "evil" websites that stop you using the browser and break
> > consistency / user expectations ("hitting <shortcut> should always do
> > <thing>").
> > 
> 
> I agree with this. I don't think we should let github override the shortcut.
> 
> It seems like the problem is that Chrome and Safari use CTRL+Shift+N for
> private browsing, while we and IE use CTRL+Shift+P (Edge doesn't have a
> shortcut) and Github must of felt that it was ok to have their shortcut only
> work in Chrome and Safari. I guess the question is do we want to change our
> shortcut for private browsing?

We use accel-shift-n for "reopen last closed window", much like accel-shift-t reopens the last closed tab. I don't think aligning with Chrome and Safari over IE would make sense over something like this, so it sounds to me like we should then just effectively wontfix this.

Comment 7

[Jarda Snajdr [:jsnajdr]]

I think there are good reasons why the Ctrl-Shift-P key shouldn't be reserved and should be available for pages to define and override.

The set of available key shortcuts is a part of the web platform API and developers should be able to reasonably predict which shortcuts they can use and which they can't.

The actions like Ctrl-N, Ctrl-T or Ctrl-W are simple key combinations - which means they are more likely to be already used by the OS or by the browser. Also, they are de-facto standardized across browsers, so developers are more likely to see there's something wrong, no matter what their primary browser is. So, making them reserved shouldn't do any harm to well-behaving pages.

The Ctrl-Shift-P is not standardized across browsers and it seems unlikely that it will be. It's a rather complex shortcut, which means it's expected to be available to the page. And it's not among the "most important" shortcuts either.

For a website developer, it can be actually quite hard to find a reasonable set of keyboard shortcuts for their app - not too simple to conflict with other actions, not too complex to become unusable, and learnable (P for Preview etc).

I don't believe the story that Github wilfully decided to support only Chrome and Safari and to ignore Firefox. First, Ctrl-Shift-P works just fine in the release version (FF 46, non-e10s) and stopped to work only lately - in nightly/e10s. Second, it sound reasonable to select a 'P' key for 'Preview' action and expect it to work.

Comment 8

[:Gijs (he/him)]

(In reply to Jarda Snajdr [:jsnajdr] from comment #7)
> For a website developer, it can be actually quite hard to find a reasonable
> set of keyboard shortcuts for their app - not too simple to conflict with
> other actions, not too complex to become unusable, and learnable (P for
> Preview etc).

The correct thing to do here for a website is to use access keys (alt-shift-<letter> on Windows) or no modifiers at all (e.g. gmail does this).

The idea that you can rely on some shortcuts to not be in use by the browser is deeply flawed, especially when considering that while the shortcuts you mention might be de facto 'standardized' in English, they can be, and often are, different in different languages.

Comment 9

[:Gijs (he/him)]

(in any case, I'm not sure to what degree it is useful to rehash the many many many arguments that have already been had about this over in bug 380637)

Comment 10

[Borek Bernard]

(In reply to :Gijs Kruitbosch from comment #8)
> (In reply to Jarda Snajdr [:jsnajdr] from comment #7)
> > For a website developer, it can be actually quite hard to find a reasonable
> > set of keyboard shortcuts for their app - not too simple to conflict with
> > other actions, not too complex to become unusable, and learnable (P for
> > Preview etc).
> 
> The correct thing to do here for a website is to use access keys
> (alt-shift-<letter> on Windows) or no modifiers at all (e.g. gmail does
> this).
> 
> The idea that you can rely on some shortcuts to not be in use by the browser
> is deeply flawed..

Those are good points, technically, but from the user perspective I find @jsnajdr's arguments closer to the reality. For example, Ctrl-Shift-P is more natural and easier to press than Alt-Shift-P, it's available for the vast majority of browser users etc. But I understand that this is a tricky issue and a balancing act.

Comment 11

[Verdi [:verdi] Best to slack me]

(In reply to :Gijs Kruitbosch from comment #6)
> 
> We use accel-shift-n for "reopen last closed window", much like
> accel-shift-t reopens the last closed tab. I don't think aligning with
> Chrome and Safari over IE would make sense over something like this, so it
> sounds to me like we should then just effectively wontfix this.

Yes, I agree that we should not change the private browsing shortcut.

Comment 12

[:Gijs (he/him)]

If we're not doing anything this should be marked wontfix.