Closed Bug 1146620 Opened 9 years ago Closed 8 years ago

Clicking Gmail desktop notification opens new window while also focusing the inbox tab

Categories

(Web Compatibility :: Site Reports, defect)

Firefox 38
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: agentme49, Assigned: karlcow)

References

()

Details

(Whiteboard: [country-all] [sitewait])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150320202338

Steps to reproduce:

1. Use Gmail.
2. In Gmail Settings, under "Desktop Notifications", make sure "New mail notifications on" is set.
3. Receive an email, see desktop notification appear for email.
4. Click the desktop notification.


Actual results:

Gmail opens the new email in a pop-up window, but then the main Firefox window becomes focused, showing Gmail in the inbox. The pop-up window is behind the main Firefox window.


Expected results:

The Gmail pop-up window should be focused and visible after the notification is clicked on.
OS: Mac OS X → All
Hardware: x86 → All
Version: 36 Branch → 38 Branch
I just tested on Ubuntu 15.10 with Firefox 43 and I still have this issue.

I've seen the issue on OS X before too. I'll leave a comment here next time I try it there. Haven't had the chance to try on Windows.
Flags: needinfo?(agentme49)
I was reproduce it on Fx44b2 Win10. It is a pop-up tab instead of window.
Status: UNCONFIRMED → NEW
Component: Untriaged → General
Ever confirmed: true
Summary: Clicking Gmail desktop notification opens pop-up but focuses main window → Clicking Gmail desktop notification open new tab to view it, but focus to Gmail inbox tab
(In reply to Justin - QA from comment #5)
> Could you all update and try to reproduce? Please let me know your findings
> so we can proceed with this bug.
I'm able to reproduce this, with a new profile, on the latest nightly build:
  * version: 46.0a1
  * build ID: 20160113030208

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Seek more information.
Component: General → DOM: Push Notifications
Product: Firefox → Core
I can repro - it's the fact that they're opening a new URL and there's a timing issue where they may not be able to set focus on it after it's opened. I wonder if chrome has the same problem. I don't believe this is specifically a Firefox bug, but gmail may need a feature or an event so they can set focus() at the appropriate time.  Note, not a regression with respect to the Push feature in fx44
Just verified that this issue is not applicable to Chrome.
It seems like they're simply not calling event.preventDefault() in their click handler to prevent the default behaviour of focusing the tab. This is documented at https://developer.mozilla.org/en-US/docs/Web/API/Notification/onclick#Examples but they obviously don't test this feature in Firefox. It would probably be useful if users report this problem to the Gmail team themselves as it's not a Firefox bug: http://grab.by/Pnhc

Karl, can you reach out to Google about this? I believe it's a one-line fix to add event.preventDefault() in their Notification.onclick handler.
Component: DOM: Push Notifications → Desktop
Flags: needinfo?(kdubost)
Product: Core → Tech Evangelism
Summary: Clicking Gmail desktop notification open new tab to view it, but focus to Gmail inbox tab → Clicking Gmail desktop notification opens new window while also focusing the inbox tab
Version: 38 Branch → Firefox 38
I tried to activate it and use Opera Blink Desktop. Without success as well.
Flags: needinfo?(kdubost)
Before contacting I would like to know where exactly in the JS it is blocking. 
That would ease the process of getting it fixed. 

Mike ?

PS: I was not able to make notifications work at all on my side with the right settings.
Flags: needinfo?(miket)
Whiteboard: [country-all] [needsdiagnosis]
Attached image notification.gif
Here's a gif showing the bug. Might be tricky to find the offending code in the Gmail codebase, but I'll start looking.

(Karl, I had to enable the notification center in OSX to reproduce, maybe you also have that disabled.)
OK, (I imagine these function and variables names will change overnight)

https://mail.google.com/_/scs/mail-static/_/js/k=gmail.main.en.KAG1eRZHr9o.O/m=m_i,t/am=PiNeC5j_e38wrjME0EofqDDv_ee7JWVnzz3-f28CROpVwP_N_h_A_8HevIUC/rt=h/d=1/rs=AHGWq9B_6ghSOvq2OSx44A52A7qIyUfh9g

Pda = function() {
        var a = Rda,
            b = uda ? function(c) { // c here is the Notification event
                /* they can prevent the default focus behavior below ---v */
                c.preventDefault();
                return a.call(b.src, b.listener, c)
            } : function(c) {
                c = a.call(b.src, b.listener, c);
                if (!c) return c
            };
        return b
    }, ....


It may be just as helpful (maybe more) to just ask that they call preventDefault() on the Notification click event (like Comment #15 suggests).
Flags: needinfo?(miket)
Thanks Mike for finding the exact culprit. Helpful.


I have contacted Google today.
Assignee: nobody → kdubost
Status: NEW → ASSIGNED
Whiteboard: [country-all] [needsdiagnosis] → [country-all] [sitewait]
This sounds like a interoperability issue. Firefox needs e.preventDefault() to make the originating window not get the focus while Chrome does not. Am I understanding correctly?
Which behavior is the correct one? What does the specification say? In case the Chrome behavior is wrong, can you file an issue at crbug.com?

Thank you!
*an
NumbStill

Google replied 4 days ago:

> Thanks for the analysis, Matthew, Mike and Karl. 
> We had been aware of this issue but didn't find 
> the time to properly investigate. I've added your 
> findings to our internal bug report (http://b/23871332).
Still - perhaps preventDefault() does not hurt Chrome, but the fact that the lack of preventDefault() hurts Firefox suggests an interoperability issue...
I agree that we don't fully understand the difference in Chrome's and Firefox's behaviour yet.

I've checked the spec and it doesn't seem to say anything about default behaviour for a notification click event.
The weird thing is that Firefox does not merely "focus" the tab associated with the notification - it opens a whole new separate window showing a single tab with the single E-mail we were notified about. I don't understand why.

Some code that seems possibly relevant:

https://dxr.mozilla.org/mozilla-central/source/dom/notification/Notification.cpp#332
      // Browser UI may use DOMWebNotificationClicked to focus the tab
      // from which the event was dispatched.

I guess next stop is here:
https://dxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#4271

case "DOMWebNotificationClicked": {

But I see nothing that looks like it would cause a separate window..
Is this Notification triggered from a Worker thread?? Perhaps we hit this code in NotificationClickWorkerRunnable::WorkerRunInternal
https://dxr.mozilla.org/mozilla-central/source/dom/notification/Notification.cpp#1370 ??
When I first started looking at this I recall seeing Chrome focus the main GMail window and opening the mail inline, while Firefox opened a popup. So I have assumed that difference in behaviour was the problem or a main reason why we were having problems. Now I retested in Chrome and all of a sudden I get the same popup behaviour (but with focus in the popup). So above few comments were probably confused and confusing.. I think the Firefox behaviour makes sense. We might want to try tracking if window.open() and/or window.focus() is used in a Notification onclick but it seems hackish.
(In reply to NumbStill from comment #21)
> This sounds like a interoperability issue. Firefox needs e.preventDefault()
> to make the originating window not get the focus while Chrome does not. Am I
> understanding correctly?
> Which behavior is the correct one? What does the specification say? In case
> the Chrome behavior is wrong, can you file an issue at crbug.com?

Firefox has the correct behaviour as Chrome hasn't updated their code to match the spec yet: https://bugs.chromium.org/p/chromium/issues/detail?id=442141

(In reply to Hallvord R. M. Steen [:hallvors] from comment #25)
> I agree that we don't fully understand the difference in Chrome's and
> Firefox's behaviour yet.

I do. Chrome doesn't match the spec change that we made for a better default UX.

> I've checked the spec and it doesn't seem to say anything about default
> behaviour for a notification click event.

It does at https://notifications.spec.whatwg.org/#activating-a-notification
"2. If the event’s canceled flag is unset, the user agent should bring the notification’s related browsing context’s viewport into focus."

(In reply to Hallvord R. M. Steen [:hallvors] from comment #26)
> The weird thing is that Firefox does not merely "focus" the tab associated
> with the notification - it opens a whole new separate window showing a
> single tab with the single E-mail we were notified about. I don't understand
> why.
> 
> Some code that seems possibly relevant:
> 
> https://dxr.mozilla.org/mozilla-central/source/dom/notification/Notification.
> cpp#332
>       // Browser UI may use DOMWebNotificationClicked to focus the tab
>       // from which the event was dispatched.
> 
> I guess next stop is here:
> https://dxr.mozilla.org/mozilla-central/source/browser/base/content/
> tabbrowser.xml#4271
> 
> case "DOMWebNotificationClicked": {

Yes, that code is implementing the line from the spec.

> But I see nothing that looks like it would cause a separate window..

Gmail is opening the window, not Firefox. The default behaviour as defined in the spec is to focus the tab/window that the Notification was created in and the bug is that Gmail gets both behaviours because they aren't calling preventDefault.
Yay! This seems to be fixed now (at least on my personal Gmail and MoCo account)! Can someone else verify and mark the bug as verified?

Thanks for reaching out to Google Karl!
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
I can confirm the fix on Mozilla/5.0 (Windows NT 6.3; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0. Extremely more user friendly!!!
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: