Hacker News Reader

Comment by 38 | Hacker News Reader

ug, nothing worse than web apps capturing my browser interactions. please don't add keyboard shortcuts, don't disable right click, don't capture Ctrl+F preventing me from using the browser search.

no, your re-implementation of existing browser feature is not better or even wanted.

View on HN

Unsure about other browsers but Firefox lets you allow/block websites from overriding default keyboard shortcuts on a per-site basis as well as globally (defaults to global allow).

Individual site config is located here: application menu bar > "Tools" > "Page Info" > "Permissions" tab > "Override keyboard shortcuts"

bless you

Unfortunately this breaks some semantically-compatible extensions to standard shortcuts, like Ctrl-C in Google Docs, which is a perfectly reasonable, necessary, and helpful override, unlike many.

I have found allowing overrides is unfortunately the least annoying of two bad options. But I still get unreasonably annoyed when web apps steal Ctrl-K which I use constantly.

On the other hand Google Docs also steals Ctrl-H which I never want to not open the browser history browser. I really wish Firefox has much more customizable keyboard shortcuts. Being about to define arbitrary bindings and control which bindings can be overridden by which sites would be an incredible productivity feature.

GitHub (and GitLab, and Linear if I recall, and others) overriding Ctrl-F (or /, which Tridactyl needs) is a crime against humanity. I know GitHub claimed they'd stop, but I still was getting weird interactions not long ago (then again, the entire recent UI redesign of GitHub drives me absolutely insane to the point that I have zero positive things to say about it, so maybe I'm just no longer their target audience).

I haven't heard any discussion about it, and second your take on the redesign. I find it harder to use, prone to the sort of unfriendly-ness discussed in this thread, and more resource intensive and/or less responsive.

I feel you, I do. I am a simple GitHub user with simple needs, and GitHub's latest redesign is a giant leap toward unnecessary complexity. I don't need multiple panels and all the geegaws. My use of GH in terms of what I need to do for my employer has become much more difficult lately. And the whole search debacle is the worst. I absolutely depended on that feature, and they somehow managed to Nerf it!

The absolute worst thing is the basic code view. If I accidentally click inside it, a text cursor shows up. Ctrl+F is then hijacked to do... previously nothing! I need to find some piece of unclickable chrome to click on and remove the "focus" from the code view, then I can Ctrl+F to find what I'm looking for with the browser's page search.

This is absolutely infuriating, and the crux of it all is that I can't even edit the code that is taking focus and hijacking shortcuts! The goggles do nothing!

> I can't even edit the code that is taking focus and hijacking shortcuts!

You can remove the shortcuts pretty easily with a userscript, see lines ~410-440 here for inspiration: https://github.com/tridactyl/tridactyl/blob/2eaba7e4ceec6de5...

The extension StopTheMadness provides similar functionality for Safari, as well as prevention of other types of annoying behaviors (like nonstandard context menus).

And for heck's sake outlook, really, did we NEED modifier-less keyboard shortcuts triggered by single letters? $deity help you if you try to type in Slack while Outlook's Web App is focused; you're likely to archive a dozen emails and possibly delete a folder.

Even though Discourse allows you to get the native Ctrl-F functionality by pressing the combination again, I hate the fact that it even captures that in the first place :(

Anyone can pose similar complaints for native apps and janky desktop environments. This has nothing to do with web apps at all.

It does have to do with web apps because web apps are built on web technologies. And those technologies involve a standardized set of events that are used to react to keyboard interactions. And those standards are deficient.

Non-web apps are subject web technology specifications.

I think I'm misunderstanding your reasoning. To me, an app's feature set and its implementation details are unrelated topics. Whether your project came from an app store, the web, a friend's USB stick, etc, is irrelevant to what it does. Ditto for the internal technologies it uses -- Qt, Electron, .NET, pure assembly, etc.

I absolutely sympathize with webpages disabling search features and so on, but I'm not sure why exactly. Pointing to app implementation doesn't seem quite right, if that makes sense.

I'm not talking about where it came from. All web apps use the "web platform". HTML, CSS, JS, DOM, and related technologies. Web apps are limited to behaviors that are possible using these technologies.

As an example, you can't make a web app that controls display brightness.* It has everything to do with the fact that it's a web app. Web apps are built on web stuff, and web stuff provides no way to do it.

So it is with keyboard events.

* As far as I know, this is true. Maybe there's some new experimental spec or something? But you get the point.

Again, you can say the same about native apps and userland. It sounds like you just don't like the way the Web APIs have expanded in scope over the last 20 years or so. This is the better future. It used to be so much uglier in the era of flash, activex, etc.

https://developer.mozilla.org/en-US/docs/Web/API

Oh and by the way the screen brightness probably can be adjusted using the USB APIs if someone bothered to port over drivers for the most common keyboards.

At least all major browsers alert the user to choose if the web app can use these APIs unlike native apps.

It's the opposite criticism. Web APIs have expanded a lot. But still not as much as native. And probably never.

Not sure what usb has to do with display brightness.

Native apps are apps, but web apps are apps in an app with already existing keyboard shortcuts

> please don’t add keyboard shortcuts

This is entirely unreasonable. Imagine Google docs not being able to offer a shortcut to enable bold formatting, for example. Terrible experience.

Sorry, no. I can't use Gmail without shortcut keys and I love Gmail with. Great job, Google engineers. Good app. Good shortcuts.

>don't capture Ctrl+F preventing me from using the browser search.

Browser search only searches visible text in the DOM. For performance reasons the whole page might not be loaded into the DOM. This means the default browser search will provide incomplete results.

if you cannot load the whole page for any reason, that's a failure of design. use pagination, that has existed since the 90s.

default ctrl-f will only search through the current page while the site-provided one can search through all content... this is not really an argument against it existing

so can a POST form request. why people feel the need to reinvent stuff that's existed for decades is beyond me

How does the user know which search to use? Ctrl-F vs search box with POST.

Forcing a request what could be done locally is bad design.

By longstanding convention. Ctrl-F is the conventional in-page search combo, while a dedicated search field is the conventional website search engine.

You can even use the OpenSearch description and move the search field to the browsers'.

But it's about inpage search, it's just a lazy loading page.

The dedicated search field is for searching my websites and the result would be a list of my pages that contain the search term. Ctrl-F jumps to the location of the search term on the page I'm already at.

Reminds me of that sort story (Asimov? Seems like him) where someone hits on the genius idea of printing thing out of the computer to read later and, after a few false starts including gigantic billboards which you have to read using sliding ladders, hits on the astounding trick of gluing thin sheets of text into portable stacks joined by one edge.

AKA books.

Well, strictly speaking it's a Holmes-Ginsbook Device, but if you want to be informal about it...

Why paginate when it doesn't make sense? I don't want a pastebin to be spread over multiple pages. I want the text file to show up on one page, but to not cause any performance issues. I want to be able to search for any line in that text file without having to search each page.

How does pagination solve the search problem?

The content you can find wih the browser search still doesn't do d the text on another page. A custom search could including a jump to the page.

Maybe, but maybe (usually) that's exactly what I wanted. Browser search has well-defined semantics, many of which are useful in ways that are not exactly 'searching the content'. These are semantically different things and overloading the shortcut is frustrating. Use a different shortcut for your incompatible functionality. For example I might use Ctrl-F to look for a UI element like 'Contact Us' that's hidden at the bottom of the page, or to refer to a stanza I read a minute or two ago without trying to find it with my eyes and the scroll bar. Or even to try to find where what I searched for appears when I have clicked on a search result. This last one is especially frustrating.

If I specifically want to search the entire corpus of data on an infinitely-scrolling site, I will use its search function intentionally, since that is a semantically different action.

This isn't some insolvable problem. Just have a separate search box and use that for cross-pagination/serverside search. Use a separate hotkey for it, like '/', as many sites do, and leave ctrl-F for the browser search.

An app without keyboard shortcuts is cumbersome to use

Emacs or vi?

Logic fallacy.

No shortcuts = cumbersome ⇏shortcuts = easy to use

Reply on news.ycombinator.com