News for hackers. Stuff that matters.
Re:On Web Extensions shortcomings and their impact on add-on... by klondike_ on Saturday November 11, 2017 @09:17PM (#15679336)
I always thought it was bizarre that WebExtensions had no UI framework. Injecting stuff into a website seems like a poor solution
Re:On Web Extensions shortcomings and their impact on add-on... by eejdoowad on Saturday November 11, 2017 @10:49PM (#15679558)
An extension overlay API would have saved me so much pain when building Saka (saka.io). There are two options for injecting UI today:

1. Inject UI directly into the document

2. Inject an iframe containing the UI into the document

Both rely on manipulating the document, which can be used to fingerprint users. Most developers opt for 1 because it requires no setup and lets the content script synchronously access the UI. 2 is needed when the injected UI containing sensitive information.

I'd like an extension overlay API that lets you inject: 1. UI local to the tab 2. UI that persists across all tabs

In a brief #webextensions IRC discussion, I was told an overlay API isn't viable for a number of reasons, one of which is multiple extensions may conflict.

Re:On Web Extensions shortcomings and their impact on add-on... by hawski on Sunday November 12, 2017 @01:45AM (#15679977)
Did they tell you how the extensions may conflict? I don't understand what it means. Couldn't it work like e.g. context menu does already for extension icon?
Re:On Web Extensions shortcomings and their impact on add-on... by eejdoowad on Sunday November 12, 2017 @06:16AM (#15680500)
What happens when two extensions try to place a widget in the same location? Chaos. Not that the status quo is any better.

Interestingly, Firefox's sidebar API only allows a single sidebar to be shown.

Re:On Web Extensions shortcomings and their impact on add-on... by drdaeman on Sunday November 12, 2017 @06:37AM (#15680532)
I still don't get it. What problem they're trying to avoid?

It's exactly the same if two extensions would currently try to manipulate the page by adding a frame (or, worse, a <div> with non-isolated UI) to the same location.

The only difference is, with out-of-page widgets (e.g. overlay regions or popouts), they won't be visible in the page's DOM.

Re:On Web Extensions shortcomings and their impact on add-on... by eejdoowad on Monday November 13, 2017 @03:49AM (#15685187)
My understanding is that if they do implement an API, they want it to be better than the status quo, not the same.
Re:On Web Extensions shortcomings and their impact on add-on... by revelation on Saturday November 11, 2017 @10:22PM (#15679495)
That's all these extensions are. Injecting stuff into websites, usually all of them.

I needed a Chrome extension after they inexplicably broke backspace navigating backwards (it literally has the same icon as the backwards UI button). That extension needs to inject a script on every. single. website.

It's like Google is spending millions upon dollars building convoluted sandboxing security features, and there is a place for that in protecting us from code execution. But then everyone is pushing for "apps on the web" and here we are with random extensions that can do everything. And they do: lots of them make money through selling your browsing history.

Re:On Web Extensions shortcomings and their impact on add-on... by nothrabannosir on Sunday November 12, 2017 @12:15AM (#15679768)
> they inexplicably broke backspace navigating backwards

Hallelujah, praise the lord! He is righteous and he is Good.

Finally. I cannot count the number of times I accidentally hit tab in a form text input, backspace, and lose the entire form. Of course it’s built in JS so state isn’t saved by browser on going forward. Because why use standards? It’s 2017, ain’t nobody got time for functionality.

It got so bad I now automatically open a text editor to write the text in, first.

This was a bug bear of epic proportions. Good riddance.

Re:On Web Extensions shortcomings and their impact on add-on... by kodablah on Sunday November 12, 2017 @09:32AM (#15680966)
Meh, backspace-for-back should not fire when a input element of any type (i.e. including anchors) have an active focus. Also, "forward" should restore this state but since it's in JS perhaps the aim of your complaints is misplaced and should direct to the site owner.

It should at least be opt in (not sure where the setting is in Chrome).

Re:On Web Extensions shortcomings and their impact on add-on... by kuschku on Sunday November 12, 2017 @05:17AM (#15680384)
That was the standard navigation method of every webbrowser for decades, not a bug.
Re:On Web Extensions shortcomings and their impact on add-on... by cesarb on Sunday November 12, 2017 @08:29AM (#15680786)
As far as I know, using backspace to go back was something from Internet Explorer, which other browsers copied as a concession to users used to it, but only on Windows. I've used Firefox for over a decade, and backspace never went to the previous page for me, even on a new install, so "every webbrowser for decades" is a stretch.
Re:On Web Extensions shortcomings and their impact on add-on... by kuschku on Sunday November 12, 2017 @09:19AM (#15680914)
Firefox on Linux has supported it for ages, too. I’ve used it frequently, at least.
Re:On Web Extensions shortcomings and their impact on add-on... by kelnos on Sunday November 12, 2017 @06:12AM (#15680493)
Just because something is and has been standard for a long time, it doesn't make it good UX.
Re:On Web Extensions shortcomings and their impact on add-on... by merlish on Sunday November 12, 2017 @06:49AM (#15680553)
It sucks that it's gone - it took me months to retrain my muscle memory to stop using backspace - but I've definitely accidentally navigated back from a form before.

I've adjusted. It's a hard decision but imo the right one. Future generations shouldn't have to deal with this.

To anyone reading who needs a keyboard-based substitute: Alt+Left Arrow.

Re:On Web Extensions shortcomings and their impact on add-on... by kuschku on Sunday November 12, 2017 @08:26AM (#15680776)
[Alt]+[←] requires two hands, though: One to press the [Alt] on the far left of the keyboard, one to press [←] on the far right of the keyboard.

That’s horrible.

Re:On Web Extensions shortcomings and their impact on add-on... by dawnbreez on Sunday November 12, 2017 @08:41AM (#15680817)
I typically use a vim-like set of keybinds when possible, so for me it's something like shift-H or g,h.
Re:On Web Extensions shortcomings and their impact on add-on... by jholman on Monday November 13, 2017 @05:35AM (#15685525)
That's weird, because I press it all the time with one hand. I don't even reliably use the same hand. Does your keyboard not have an Alt key to the right of the space-bar?
Re:On Web Extensions shortcomings and their impact on add-on... by kuschku on Monday November 13, 2017 @11:39AM (#15687715)
On international keyboards, there is no right alt key, but instead at that place is [AltGr], which triggers both [Alt] and [Ctrl].

[AltGr]+[M] for example gives μ, [AltGr]+[E] gives € and [AltGr]+[Q] gives [@]. Obviously, [AltGr]+[←] doesn't work.

It's one more of those shortcuts that make it obvious that whoever made the decision only ever used a US Standard keyboard, and never even considered international users. The only decisions even worse are ever using ` (it's a 4 key combo on some international keyboards, and not at all existing on others), or ~ \ [ ] { } ( ) ; : (all of these are combinations of usually two or three keys on most international keyboards).

Re:On Web Extensions shortcomings and their impact on add-on... by tyingq on Saturday November 11, 2017 @09:44PM (#15679394)
There is a bit of separate ui, both for the config page and the div (popup panel) that pops when you click the extension button.

What were you looking for instead?

Re:On Web Extensions shortcomings and their impact on add-on... by singularity2001 on Sunday November 12, 2017 @05:08AM (#15680370)
the problem with the Pop-Up panel is that you cannot open it programmatically