1452910 - Add tab hover event to tabs API

Status: RESOLVED DUPLICATE of bug 1246706

(WebExtensions :: Frontend, enhancement)

Description

[lolipopplus]

User Agent: Mozilla/5.0 (X11; U; FreeBSD i386 6.98; rv:6.51) (KHTML, like Gecko)  Safari/65.56 Chrome/6.51;
Build ID: 20180404171943

Steps to reproduce:

move your mouse onto any tab


Actual results:

WebExtension is not firing any event


Expected results:

An event should be fired with returning tab info

Comment 1

[lolipopplus]

because that there is a feature in tab mix plus:
select the tab on mouse hover after X ms

Comment 2

[Michael P.]

A "select tab on mouse hover for n amazon of time" feature would be very useful, especially for accessibility.

Comment 3

[Michael P.]

amount of time

Comment 4

[lolipopplus]

then I would like to set up this flag as comment 2

Comment 5

[Caitlin Neiman [:caitmuenster]]

Hi lolipopplus, this has been added to the agenda for the WebExtensions APIs triage on May 8. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1TRkZ2u3GQXwlHpfP4-P_SXcwIwvlQz5Sm-C8I89Ya_o/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 6

[Tim Nguyen :ntim]

Another nice use case is tab previews on hover.

Comment 7

[lolipopplus]

(In reply to Caitlin Neiman [:caitmuenster] from comment #5)
> Hi lolipopplus, this has been added to the agenda for the WebExtensions APIs
> triage on May 8. Would you be able to join us? 
> 

I check the time, that was 4AM at my local time (GMT+8), so very unlikely.

But I'm pretty sure I will be here whenever you guys flags me up

Comment 9

[Caitlin Neiman [:caitmuenster]]

This concept was denied in the design-decision meeting; Luca to follow up with a summary of how we arrived at that decision.

Comment 10

[Luca Greco [:rpl] [:luca] [:lgreco]]

This API request has been discussed during the last design-decision meeting and we agreed to deny it, as for the similar Bug 1246706 (which this bug is now marked as a duplicate of).

In Bug 1246706 we have already denied the generic concept of adding arbitrary listeners to mouse API events related to the tab browser UI, and between all the mouse events discussed in that bug (e.g. click / double-click etc.), the mouse hover is definitely the more "transient one", and it is even more likely to potentially be subject to "race conditions" (and related unexpected behaviors) and performance issues (e.g. an extension, even not maliciously, may introduce performance issues by running a heavy task on an event that is potentially fired very often and potentially too late to do anything useful with the work done by that heavy task).

Comment 11

[Martijn]

Please stop being so arrogant.
You removed almost ALL extension functionality in the first place. And know you refuse to add back one simple event listener?

You're basically making it impossible to create an extension for proper mouse gestures, and you've also been discussing to add those natively for 15000 years. Makers of these extensions are being put their back against the wall. On the one hand, users are angry that their mouse gesture extensions are so ****, because someone decided to remove nearly everything that pertains to extensibility and replace it with the atrocious WebExtensions. And on the other hand the same developers have absolutely no way to make their mouse gesture extensions any better, because of the same reason.

This is what we call a "dick move", Mozilla.

Comment 12

[lolipopplus]

(In reply to Luca Greco [:rpl] from comment #10)
> This API request has been discussed during the last design-decision meeting
> and we agreed to deny it, as for the similar Bug 1246706 (which this bug is
> now marked as a duplicate of).
> 
> In Bug 1246706 we have already denied the generic concept of adding
> arbitrary listeners to mouse API events related to the tab browser UI, and
> between all the mouse events discussed in that bug (e.g. click /
> double-click etc.), the mouse hover is definitely the more "transient one",
> and it is even more likely to potentially be subject to "race conditions"
> (and related unexpected behaviors) and performance issues (e.g. an
> extension, even not maliciously, may introduce performance issues by running
> a heavy task on an event that is potentially fired very often and
> potentially too late to do anything useful with the work done by that heavy
> task).

So, is this indicating that parts of Tab Mix Plus won't be supported anymore?

Comment 13

[Mike Hoye [:mhoye]]

"Please stop being so arrogant."

Martjin, Bugzilla is our professional working environment as much as it is our issue tracker, and comments like this are not an acceptable use of it. If you intend to continue participating in Bugzilla, I encourage you to review our etiquette and contributor guidelines and take their advice to heart.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Thank you.

Comment 14

[klorinczi]

(In reply to Luca Greco [:rpl] from comment #10)
> This API request has been discussed during the last design-decision meeting
> and we agreed to deny it, as for the similar Bug 1246706 (which this bug is
> now marked as a duplicate of).
> 
> In Bug 1246706 we have already denied the generic concept of adding
> arbitrary listeners to mouse API events related to the tab browser UI, and
> between all the mouse events discussed in that bug (e.g. click /
> double-click etc.), the mouse hover is definitely the more "transient one",
> and it is even more likely to potentially be subject to "race conditions"
> (and related unexpected behaviors) and performance issues (e.g. an
> extension, even not maliciously, may introduce performance issues by running
> a heavy task on an event that is potentially fired very often and
> potentially too late to do anything useful with the work done by that heavy
> task).

I stopped upgrading Mozilla Firefox to latest release (downgraded to Firefox ESR), because it dropped compatibility with "Legacy" Add-ons.
But "Legacy" means more something like "Standard".

I use Tab Mix Plus and Session Manager add-ons since years, so they became "STANDARD" for me.
These are functionalities, which SHOULD be part of Mozilla Firefox by default. 
And now Mozilla, the company following the strict industry standards ignored these "LEGACY->STANDARD" add-ons, and made them incompatible with latest Firefox. 
No backward compatibility. Gone.
No industry standard sensitivity. Gone.
Not a user friendly decision. This is true.

Currently I use Firefox ESR v52.7.3 (64-bit), because this is the last supported/developed version, which provides compatibility with standard Add-ons like Tab Mix Plus and Session Manager.
Once Firefox ESR development will stop, I will look for another browser, which will be likely based on the same browser engine and will provide similar features like Firefox had.

I'm a user.
I'm a developer. 
You lose both.

And likely thousands of actual Firefox users will think the same way.

There is one way to keep your users:
Provide them backward compatibility with "LEGACY->STANDARD" add-ons while you implement new technologies like web extensions.

Comment 15

[Martijn]

It's true though.

Someone asks for a feature. One's that pretty darn simple to implement. One that shouldn't impose security risks. One that has existed for many years in the past.

Then, you hold a discussion elsewhere, keeping everyone else involved at bay. And then you conclude to deny this very simple request, just like that.

Etiquette or not, that is what I call arrogance.

Comment 16

[Caitlin Neiman [:caitmuenster]]

Hi all, conversations in this bug have stopped being productive and have turned into an argument. I am closing comments on this bug.