Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 56764 Regression - Desktop Notifications only receives keyboard events when its browser window has the focus
Starred by 24 users Reported by phistuck@gmail.com, Sep 24, 2010 Back to list
Status: WontFix
Owner: johnnyg@chromium.org
Closed: Jul 2013
Cc: johnnyg@chromium.org, dglazkov@chromium.org
Components:
OS: All
Pri: 2
Type: Bug


Sign in to add a comment
Chrome Version       : 7.0.517.8 dev

What steps will reproduce the problem?
1. Create a desktop notification with an input field and make it show up.
2. Type "I can see me typing." in the input field of the desktop notification.
3. See "I can see me typing" being typed in the input field of the desktop notification.
4. Delete what you typed.
5. Focus on a different window (Windows Explorer, Google Talk, a Google Chrome window with a different profile - everything but the current browser profile, Notepad).
6. Focus on the input field.
7. Type "Can you see me typing?".

What is the expected result?
The text will show up in the input field of the desktop notification.

What happens instead?
If you focus Notepad, it will get this input and you will see "Can you see me typing?" being typed in Notepad.

Code sample (execute it in the Omnibox) -
javascript:webkitNotifications.requestPermission(function(){webkitNotifications.createHTMLNotification("data:text/html,<!DOCTYPE HTML><html><body>Drag me<br/><input/></body></html>").show()});
 
Comment 1 by phistuck@chromium.org, Sep 24, 2010
Labels: -Area-Undefined Area-UI Area-WebKit Feature-Notifications Regression WebKit-Core Mstone-7
Status: Untriaged
Status: Assigned
John, can you look into this?  Adjust priority/mstone if needed.
Labels: -Regression -Mstone-7 Mstone-8
Are you sure this worked before?  There are known issues with inputs in notifications, which are slated for m8.
Comment 4 by phistuck@gmail.com, Oct 2, 2010
John, I am sure this has worked before. It was fine before, there were other issues, but this specific issue - it was not happening before.
Does it work in 6.0?  I can't think of anything that changed in this area for M7, but I will look.
Comment 6 by phistuck@gmail.com, Oct 2, 2010
I can reproduce it on 6 as well, but it was fine before...
Comment 7 by lafo...@chromium.org, Oct 19, 2010
Labels: -Mstone-8 Mstone-9
Since we are passed the branch, moving all mstone-8 issues to mstone-9 for triage/punting
Comment 8 by lafo...@chromium.org, Oct 22, 2010
Labels: Mstone-10
Moving all P2 bugs w/ owners into Mstone-10.  I'll leave this to the owners discretion if they want to move the work back into M9, however, my caveat would be that the priority should be on completing P0/P1 bugs in the span of the next few weeks.
Comment 9 by kerz@chromium.org, Dec 9, 2010
Labels: -Mstone-10 MovedFrom-10 Mstone-11
P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.
Desktop notifications launched by extensions (with input fields), exhibit similar behavior. A chrome window needs focus, and then the desktop notification needs focus before the input box can be typed into.

Desktop notification input box shows focus (orange outline), but typing will go to whatever program/window has focus, not the desktop notification.
Comment 11 by kareng@google.com, Mar 9, 2011
Labels: -Mstone-11 MovedFrom-11 Mstone-12
rolling non releaseblocker mstone 11 bugs to mstone 12. 
Comment 12 by k...@google.com, Apr 25, 2011
Labels: -Mstone-12 Mstone-13 MovedFrom12
Moving out of M12.
Comment 13 by calebegg@gmail.com, May 19, 2011
Labels: OS-All
On both Mac and Linux, this doesn't even work if the browser window is focused. The notification's form elements are basically unfocusable.
Comment 14 by flashki...@gmail.com, May 19, 2011
I'm not sure how user-friendly this method is. But, as a replacement, I just created a window that auto-refocuses itself, positions and sizes itself just like a notification. It's worked out really well, almost no functionality lost.
I'm starting to get a lot of complaints about this issue (I use desktop notifications as an important part of a chrome extension). Is there some way to fix/bypass this without reimplementing the entire notification system?

I've tried having the parent window automatically refocus itself (seems to be required by this bug), but then I can't get the notification to regain focus for typing. 
Labels: -Mstone-13 Mstone-14 MovedFrom13
Moving !type=meta|regression and !releaseblocker to next mstone
Comment 17 by evan@chromium.org, Jun 2, 2011
Ping.  Someone from the gmail team says this might be blocking them.
This becomes more problematic with the new "background" permission for extensions. Notifications created by an extension with no windows active creates an unfocusable desktop notification.
Labels: -MovedFrom12 MovedFrom-12
Cc: dglazkov@chromium.org
Is anyone working on this?
Comment 21 by k...@google.com, Jul 28, 2011
Labels: -Mstone-14 Mstone-15 MovedFrom-14
Punting out non-critical bugs.  Please move back to 14 if you believe this was done in error.
Comment 22 by kareng@google.com, Sep 8, 2011
Labels: Mstone-16 MovedFrom15 bulkmove
moving non-essential bugs from 15 to 16. Please feel free to move back if this is an error and your bug is a blocker for 15.
Comment 23 by laforge@google.com, Oct 24, 2011
Labels: -Mstone-16 MovedFrom-16 Mstone-17
Comment 24 by k...@google.com, Dec 19, 2011
Labels: -Mstone-17 Mstone-18 MovedFrom-17
Moving bugs marked as Assigned but not blockers from M17 to M18.  Please move back if you think this is a blocker, and add the ReleaseBlock-Stable label.  If you're able.
Comment 25 by mihaip@chromium.org, Jan 20, 2012
Cc: johnnyg@chromium.org
Issue 108891 has been merged into this issue.
Comment 26 by kareng@google.com, Feb 7, 2012
Labels: MovedFrom18 Mstone-19
Comment 27 by laforge@google.com, Mar 27, 2012
Labels: -Mstone-19 Mstone-20 MovedFrom-19
Comment 28 by k...@google.com, Apr 27, 2012
Labels: -Mstone-20 MovedFrom-20
These bugs have hit their limit of moves to new milestones.  Please retarget when appropriate.
Project Member Comment 29 by bugdroid1@chromium.org, Mar 10, 2013
Labels: -Area-UI -Area-WebKit -Feature-Notifications -WebKit-Core Cr-UI-Notifications Cr-Content Cr-UI Cr-Content-Core
Project Member Comment 30 by bugdroid1@chromium.org, Apr 6, 2013
Labels: -Cr-Content Cr-Blink
Any workaround yet ? 
Comment 32 by somast@chromium.org, Jul 17, 2013
Status: WontFix
createHTMLNotification has been deprecated. Please use the rich notifications API (http://developer.chrome.com/apps/notifications.html) for creating notifications. 
Sign in to add a comment