Site captures Cmd-F -- Is this the future of the Web?

[thom-22]

I came across a case, at the Google Books website, in which pressing Cmd-F put a blinking cursor in the page's search box instead of opening Camino's find-in-page bar. Appalled, I undertook the usual bug-testing procedures and discovered that the same thing happens in latest Safari, latest Chrome, and Firefox 3.0, 3.5, 3.6 & 4b, but not in Camino 1.6 & 2.0.4. So I guess this is expected behavior now? If so, one smiley is not enough to convey my contempt:

Now it turns out the issue is not a big deal in the one instance I found it -- it doesn't happen on every Google Books page, only on those entries that display images of pages from a physical book with a sidebar on the left, like here; there really isn't any text on the page worth searching.

But my concerns are broader: Why should a website be able to override the interface of a program I've chosen to use, especially wrt a feature so deeply ingrained in the OS I've chosen to use. (How long has Cmd-F meant "find in page" in document-based applications on Mac? 20 years at least!) How is it appropriate that choosing a menu item (Edit -> Find in Page...) does something different than pressing the keyboard shortcut that's clearly listed next to it? How many other sites are going to hijack this shortcut for their own nefarious data-gathering, revenue-generating purposes? When I say "find in page", I mean "find in page"; it's not up to the website I'm on to do something else, even if that something else might be more useful. WTF is the Web coming to? Time for some comic relief:

Is this issue encompassed by Bug 459744? I have followed that bug with interest, pleased that the Camino developers represent the voice of reason there. I further gather that Bug 569130 overrides some of the Gecko nonsense? I would argue that Cmd-F and related shortcuts ought to be included on the whitelist. Would I be alone on that?

[cflawson]

Those are all pretty much the same arguments we've made in the two bugs you've pointed out (though the first has been duped), and I agree with you that Cmd-F should probably be whitelisted.

cl

[phiw13]

Interestingly, I can't reproduce it on the page you point out . That page has no left hand side bar, as loaded here. I can repro the 'problem' when I perform a search from the search field at the top of the page, next to the google books logo, and then click on one of the results.

On those pages, one can eventually argue that it is a friendly thing, as that search field in the left-hand sidebar has a placeholder 'search in this book' (and one can't search in that book from camino's search bar). It is a tricky thing, some websites are more application like and try to mimic real desktop applications (e.g. google docs and other g. apps). I have no idea if Cmd-F is used by Google docs, I can imagine it being useful to search inside a long document - one that is not fully displayed on screen, just like that google books search goes inside the book). Bug 569130 prevents sites from highjacking some of the most vital shortcuts - and thus prevents a stupid site from blocking out a keyboard user completely, and leaves some freedom for the others.

I'm not so sure that Cmd-F ought to be whitelisted, personally. Although it would massively annoy me if Google highjacked that shortcut for their general search pages.

[bilbar]

I found the same behavior as described by Thom-22 on that page.

[thom-22]

Interestingly, I can't reproduce it on the page you point out . That page has no left hand side bar, as loaded here.

It does when I click on the link.

I can repro the 'problem' when I perform a search from the search field at the top of the page, next to the google books logo, and then click on one of the results.

Yes, that's exactly how I got to the page I linked to.

On those pages, one can eventually argue that it is a friendly thing, as that search field in the left-hand sidebar has a placeholder 'search in this book' (and one can't search in that book from camino's search bar). It is a tricky thing, some websites are more application like and try to mimic real desktop applications (e.g. google docs and other g. apps). I have no idea if Cmd-F is used by Google docs, I can imagine it being useful to search inside a long document - one that is not fully displayed on screen, just like that google books search goes inside the book). Bug 569130 prevents sites from highjacking some of the most vital shortcuts - and thus prevents a stupid site from blocking out a keyboard user completely, and leaves some freedom for the others.

Absolutely it's friendly -- Big Brothers always try to come across as friendly. I'm not going to dispute that 99 out of 99 people who press Cmd-F there really do want to find text not in the web page but in the book that is the subject of the web page, that the average user wouldn't even make the distinction between the two.

I'm not so sure that Cmd-F ought to be whitelisted, personally. Although it would massively annoy me if Google highjacked that shortcut for their general search pages.

Why not? What criteria would you use to determine which shortcuts should be whitelisted and which shouldn't? I freely admit that I can't come up with any arguments for whitelisting Cmd-F that wouldn't also apply to any other keyboard shortcut. As I've thought about it more, I realize I don't want to be involved in debates about individual shortcuts, as it's my contention that websites should never be able to capture any keyboard shortcut that is already in use by the browser or the OS (at least not without my permission). And woe to the first site that hijacks a shortcut I've assigned to custom functionality via an Automator Service!

That one site has used the capability benignly is hardly reason to accept the capability itself as a good idea or to dismiss the huge potential it has for mis-use.

[cflawson]

I personally don't think the browser content area should have any control whatsoever over the Command key on Mac OS. That key is reserved for OS use and should never even be propagated that far down the chain.

cl