I think we said in the Nov 15th meeting that this was something we won't fix. According to the meeting notes it said "this is something we will likely do in settings". Kris can you comment on this please so we can justify the won't fix?

A few observations:
- it looks like several different use-cases could be covered with this API
- I don't see any obvious disadvantages to implementing this (wrt encapsulation or performance)
- we could rate-limit the MouseMove events if needed (though I doubt even that would be a problem)
- no new low-level details need to be exposed to make this work (we already have a Tab abstraction)
In light of this, I would like to ask for re-examining the decision on this bug, or at least make it P5 "will take patches", as it seems several existing extension developers (who could work on this) are interested in the API.

(In reply to matthamilton from comment #7)
> My add-on, https://github.com/mthamil/Tab-Wheel-Scroll, requires listening
> for mouse scroll events on the tab bar.
And this extension is necessary for Firefox to match the tab-bar behaviour common to every other application on a Linux desktop.
On Linux, I can personally attest that spinning the scroll-wheel on a tab bar switches tab focus in:
* anything using GTK+'s GtkNotebook
* anything using Qt's QTabWidget (which should include Opera, as I remember)
* anything using wxWidgets' wxNotebook (because it wraps GTK+ on Linux)
* Chrome/Chromium
While I don't have any Java GUIs handy at the moment, that should also mean that anything Java-based which uses SWT (eg. Eclipse, Vuze) will behave that way, since SWT works as a toolkit abstraction layer similar to wxWidgets and wraps GTK+ on Linux.
Firefox is a glaring exception to platform norms in this way... especially given how much its interaction paradigm encourages switching tabs.

An attempt to port FireGestures could also use an ability like this, but extended to the full chrome/window, not just tab elements. I noticed this through a recent discussion here: https://www.reddit.com/r/firefox/comments/642oax/i_created_a_mouse_gestures_web_extension_as_a/
Without the ability to detect mouse events except through a content script, it's impossible to detect gestures while a loading tab has stalled, or on restricted pages. This is a sub-par UX for gestures that allow opening/closing tabs, for instance.
Would it not be possible to just allow background scripts to listen for mouse/touch events on all windows, just with drastically reduced information/abilities returned on secure pages and chrome elements? As in something like this:
// in a background.js
window.addEventListener("mousedown/touchstart/etc", function(evt) {
evt.target === undefined
evt.targetType === "content-element", "chrome-element", chrome-tab", "chrome-devtools", etc, as desired by the user-agent.
evt.tabId, windowId, and frameId are set so that addon can distinguish them.
evt.windowId is instead set when a non-tab chrome element is being interacted-with.
evt.pageX/pageY/offsetX/offsetY/etc could be undefined (unless desired for some reason).
evt.movementX/Y would at least be available for gesture-tracking purposes.
evt.preventDefault/stopPropagation could be ignored except where desirable (ie, on tabs).
});
There would not need to be any guarantees about which targetTypes (or how fine-grained they are) each user-agent would expose. Nor could there be, as users may already hide UI elements in most user-agents. But this would still allow consistent gesture-tracking and basic chrome-interactions to be detected without breaking restrictions. User agents could also hide more details behind permissions, as desired.
I believe this would satisfy a significant number of use-cases like the ones presented in this bug, as well as for addons like FireGestures (I'm just not sure if pointer-locking would also need to be exposed for gestures). Addons could coordinate these listeners with the ones seen by content scripts, so there would be no need to have a mousemove listener in every tab's content script, so there may be a performance benefit for some use-cases as well.
One consideration that may prove tricky is that if extensions would be permitted to "replace" UI elements, they should probably be allowed to specify a targetType of their own (and potentially specify a tabId/etc as needed somehow).

WebExtensions are about providing interaction with web content and less focusing on the browser chrome.
For example: being able to scroll up and down, using a mouse on the tab strip is already something in Firefox and capturing those events could potentially break it. There were also questions in the meeting about how this would work once WebExtensions are in their own process.
Whilst this bug is specifically about tabs, its about allowing specific events on the user interface to be captured and that's something that we've been avoiding as much as possible because of extensions breaking the browser chrome.

In that case, would you mind putting bug 1285812's priority up for reconsideration?
Firefox's default behaviour is a serious UX wart on Linux desktops, where all major widget toolkits (as well as Chrome/Chromium) map "scroll wheel on a tab bar" to "change tab focus".
(In fact, it's a serious enough break from my muscle memory that, as a backup plan, I've started speccing out a utility which functions sort of like a keylogger under the hood, but instead hijacks scroll events on the top 37px of any window with WM_CLASS = ("Navigator", "Firefox") and replaces them with synthesized Ctrl[+Shift]+Tab X11 events.)

It's funny because Jared said, just 10 months ago in that bug:
> At this point, it would be functionality better left for an add-on, allowing users to opt-in to the changed behavior that they want.https://bugzilla.mozilla.org/show_bug.cgi?id=1285812#c2
That is going to be impossible.

(In reply to Andy McKay [:andym] from comment #16)
> WebExtensions are about providing interaction with web content and less
> focusing on the browser chrome.
>
> For example: being able to scroll up and down, using a mouse on the tab
> strip is already something in Firefox and capturing those events could
> potentially break it. There were also questions in the meeting about how
> this would work once WebExtensions are in their own process.
>
> Whilst this bug is specifically about tabs, its about allowing specific
> events on the user interface to be captured and that's something that we've
> been avoiding as much as possible because of extensions breaking the browser
> chrome.
How about mouseover (for tab preview on mouse over) or doubleclick events ?
I don't see how those 2 are affected by any of the 2 problems you've mentioned.

(In reply to Andy McKay [:andym] from comment #16)
> Whilst this bug is specifically about tabs, its about allowing specific
> events on the user interface to be captured
Why would the event need to be captured? If my add-on listens to double click events, I don't mind if some existing Firefox code also receives the event...

(In reply to Andy McKay [:andym] from comment #16)
> WebExtensions are about providing interaction with web content and less
> focusing on the browser chrome.
Maybe for you, but there are a lot of people out there who would not agree and just want to get the same functionality they have today provided through extensions. And they won't mind if the browser doesn't work the default way, because that's the whole point of getting an add-on
> For example: being able to scroll up and down, using a mouse on the tab
> strip is already something in Firefox and capturing those events could
> potentially break it. There were also questions in the meeting about how
> this would work once WebExtensions are in their own process.
If I want to, I can write an add-on today that breaks all websites by injecting some content script. And that's OK, because users have the choice and have to give the permission. Nobody would think about taking this possibility away?
I don't see how a different processing model would change anything. Firefox allows context menus on tabs, how is a click there different from a left click on a tab?
> Whilst this bug is specifically about tabs, its about allowing specific
> events on the user interface to be captured and that's something that we've
> been avoiding as much as possible because of extensions breaking the browser
> chrome.
The problem is: Firefox today is broken. It is not providing the functionality people want, that's why they write add-ons. If everything that I want would be built-in, I would not need to spend my evenings trying to fix my experience.

> How about mouseover (for tab preview on mouse over) or doubleclick events ?
We don't have any other events like this in WebExtensions. We've been repeatedly pointing people to building their own tab strip in HTML as a sidebar where they can do whatever they want.
> The problem is: Firefox today is broken. It is not providing the functionality people want, that's why
> they write add-ons. If everything that I want would be built-in, I would not need to spend my evenings
> trying to fix my experience.
And I get it. But this is the fundamental difference between what people used to do with add-ons and what WebExtensions are for. The goal of WebExtensions is different from what it used to be for add-ons. Every design decision in Firefox's history and every controversial thread in a mailing list that resolved in "just write an add-on" is part of the problem people have with WebExtensions.
You can do whatever you want on Nightly and "fix" Nightly as you want, because you can load bootstrapped add-ons there.

(In reply to Andy McKay [:andym] from comment #22)
> You can do whatever you want on Nightly and "fix" Nightly as you want,
> because you can load bootstrapped add-ons there.
How stable is nightly, generally?
Aside from the expected breakages from writing extensions against APIs now considered internal, would I be setting myself up for significantly more pain if I migrated my mother over to it?

(In reply to Andy McKay [:andym] from comment #22)
>We've been repeatedly pointing people to building their own tab strip in HTML as a sidebar where they can do whatever they want.
And what if there are two add-ons wanting to do different things? Do I need two tab bars, three,... ? Also, I wouldn't want to change how Firefox looks like. It's hard enough already to get a consistently looking UI as it is.
> And I get it. But this is the fundamental difference between what people
> used to do with add-ons and what WebExtensions are for. The goal of
> WebExtensions is different from what it used to be for add-ons. Every design
> decision in Firefox's history and every controversial thread in a mailing
> list that resolved in "just write an add-on" is part of the problem people
> have with WebExtensions.
When I read https://developer.mozilla.org/en-US/Add-ons/WebExtensions/What_are_WebExtensions it sounds very different though. Especially the "add-ons can add new features to the browser" part. And I get that you want to provide an API so add-ons don't break with regular updates because they access internals. But just saying we won't do it because webextensions are not meant to do it, where the existing documentation or communication doesn't say so is just bad in my opinion. Or can you point me to some other place where it's spelled out what webextensions are for?
> You can do whatever you want on Nightly and "fix" Nightly as you want,
> because you can load bootstrapped add-ons there.
The nightly is not stable enough though.

bug 1367187 isn’t a duplicate. it’s about the tab bar, not individual tabs
and yeah, i’m going to jump on the bandwagon and say:
i have a very simple addon that just reacts to a click event on some UI element (in my case the tab bar, for this bug report the tabs)
this should be possible with WebExtensions, else they will never be able to replace other addons.

(In reply to Andy McKay [:andym] from comment #27)
> The reasoning is the same, this outside of the WebExtensions scope.
How? WebExtensions are supposed to be a replacement for add-ons. They are not an adequate replacement if they don't even provide basic functionality such as this. Even CSS can listen to these sorts of events. (The :active selector, and the :focus selector) Also, so what if they can "break the UI"? Add a warning that the add-ons can change or break the UI if they have certain permissions when installing them if it matters so much to cater to users who don't know what they're doing. Put it in scary bold red font if you have to. (with "WARNING:" before, for good measure)

> You can do whatever you want on Nightly and "fix" Nightly as you want,
> because you can load bootstrapped add-ons there.
Except I would probably have to code it myself, seeing as not that many people will code something specifically for unstable builds, and the fact this is basic stuff expected from add-ons in Firefox. I shouldn't HAVE to go to such a measure for an add-on to be able to use such a basic add-on functionality.

(In reply to Andy McKay [:andym] from comment #27)
> The reasoning is the same, this outside of the WebExtensions scope.
You are incorrect. The scope of WebExtensions is to replace the current Addon system. In fact, Mozilla has said multiple times that the goal is to make sure that all of the top 10 addons are able to be ported. Tab Mix Plus depends on this.

(In reply to Andy McKay [:andym] from comment #35)
Not to start anything new up (I just want to make my point and leave. Hence, not worth joining a mailing list.), but that could be a big PR backfire if it gets taken as evidence that earlier reassurances were knowing lies.
Also, the links you gave for [1] are contradictory, since "give users more control over their web experience" is inherently something you can't do if you reduce the scope of how extensions are capable of bringing about what a given user desires. (Again, giving the impression that marketing people are promising what engineering has no intent to deliver.)

Another collector contradiction from the link:
"We don't want to limit what add-ons can do in Firefox. We will work with every developer who is interested to make their add-on work in Firefox, and work to provide the functionality required in as many cases as possible."
These WONTFIX decisions will slowly sign Firefox death warrant for sure.

What WONTFIX?!
What moron decides this? Just fix the damn webextensions. *You* decided to kill almost all extensions, and *you* decided to replace XPCOM with a **** framework that can do virtually nothing. Now it's time to eat the consequences.
Get off your lazy bottoms and fix this ****.
You can also decide to get XPCOM back, because no-one benefits from its absence!

(In reply to gh from comment #37)
> Another collector contradiction from the link:
Those parts of the wiki are from 2015 and written by others. I updated them and put text at the top saying: "Some of these are relevant, but come from an FAQ around the decision to implement WebExtensions in August of 2015. They may not still be relevant." rather than just delete them in the effort of transparency. Perhaps we should delete them to prevent confusion.

(In reply to Martijn from comment #41)
> Hi Caitlin,
>
> Mozilla just shouldn't have made such a godawful nightmarish mess from hell
> by ditching the most brilliant add-ons framework and replacing it with
> relatively nothing.
As a programmer, I have to disagree.
The purpose of a programming interface is to present a maintainable view of things and XUL+XPCOM failed hard at that.
From the addons side, it was wasting a ton of developer effort. Look at the guts of a long-lived Firefox extension and you'll see a ton of "If version A, do B. If version X, do Y." because extensions are mucking about in the raw guts of Firefox. (That's actually what drove me to use Greasemonkey to create my "addons". A stable API.)
...not to mention being harder to get familiar with than WebExtensions, being generally lower-level and less thoroughly documented.
From the browser side, it was crippling Firefox too much. The whole reason Firefox is so far behind Chrome on the multi-process front is because they spent so much time trying to make it work without breaking addons... an effort which they eventually had to admit defeat on.
While I definitely think that the WebExtensions concept has been an increasingly big disappointment ever since the quiet retirement of the "native.js" idea for allowing addon developers to ship their own API extensions to stable Firefox until some version gets accepted (and I'll be leaving Firefox if something like PyQt's QWebEngine widget gains WebExtensions support so I can write my own custom frontend in Python), I certainly don't want to look at the old APIs through rose-colored glasses. They were the most powerful but certainly not the most brilliant.

Hi folks, comments on this bug will now be restricted. As mentioned in comment 39, Bugzilla is an issue tracker and not an advocacy forum. At this point, this bug has stopped providing useful information and has become an argument.
If you would like to continue the conversation, please see comment 35 for mailing list information.