1009190 - preventDefault should be respected when clicking on a DOM Notification

Status: RESOLVED DUPLICATE of bug 874050

(Core :: DOM: Core & HTML, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

When clicking on a DOM notification, Firefox switches to the originating tab. This is useful in most cases, but some websites prefer to either not have the tab switch or to open their own window upon clicking on the notification.

If the website uses preventDefault, we should not switch to the originating tab.

Comment 1

[Anne (:annevk)]

What Firefox highlights is up to its UX. And the click event is not pluggable per the specification.

Comment 2

[Björn Kautler]

As this issue is created due to my feedback I thought it might be a good idea to have it in here also.
Copied from https://bugzilla.mozilla.org/show_bug.cgi?id=853972:

> Is this the right place to say that I ABSOLUTELY dislike this "feature"?
> It kind of breaks the GMail workflow.
> 
> Before this change when a new mail arrived, a desktop notification was shown.
> If I clicked it, a new FF popup was opened with the mail in it.
> Everything else in my work environment stayed as it was.
> The program I had focus still is the second window behind the mail,
> or if FF was the active window, the tab I was working on was still the active tab.
> 
> Now with this change, if I click the notification,
> FF is brought to front and the GMail tab made the active tab.
> This brings absolutely no gain, it just disturbs workflow.
> After I opened a mail from notification now, I have to find
> out where the program is that I worked with or which of the
> dozens of open tabs was the one I was working on.
> 
> This is really not comfortable to work with.
> If you insist on providing this feature, please make it configurable.
> Maybe for some pages it makes sense to behave like that, but then please
> make it configurable by page.
> Or provide a button in the notification that opens the originating tab so
> that one can click the button to open the originating tab or click the
> remaining notification to do whatever the notification is supposed to do
> like opening the mail in a popup for GMail.

Comment 3

[Anne (:annevk)]

It sounds like you complained about UX. I don't understand why this is a bug against Core.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

I suspect we will have to make some changes to dom/src/notification/Notification.cpp, which is what dispatches the chrome event "DOMWebNotificationClicked". We may also need to modify some front-end code as well. You can see the patch that implemented this behavior in the linked bug (bug 853972).

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

jaws, is there a spec bug for this behavior?
Making the event cancelable sounds totally ok to me, but we need to fix the spec first.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Hmm, I don't even know where to file Notification spec bugs.

Comment 7

[Anne (:annevk)]

See http://notifications.spec.whatwg.org/ under "Participate".

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Bug reported  http://logs.glob.uno/?c=freenode%23whatwg&s=15%20Aug%202014&e=15%20Aug%202014#c902143

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

I'm doing the work in Bug 874050

Comment 10

[Matthew N. [:MattN]]

I believe the doDefaultAction check handles this.