Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 24 users
Status: WontFix
Email to this user bounced
Closed: Jul 2013
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment
Regression - Desktop Notifications only receives keyboard events when its browser window has the focus
Project Member Reported by, Sep 24 2010 Back to list
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()});
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, 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, Oct 2 2010
I can reproduce it on 6 as well, but it was fine before...
Labels: -Mstone-8 Mstone-9
Since we are passed the branch, moving all mstone-8 issues to mstone-9 for triage/punting
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, 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, Mar 9 2011
Labels: -Mstone-11 MovedFrom-11 Mstone-12
rolling non releaseblocker mstone 11 bugs to mstone 12. 
Comment 12 by, Apr 25 2011
Labels: -Mstone-12 Mstone-13 MovedFrom12
Moving out of M12.
Comment 13 by, 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.
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, 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
Is anyone working on this?
Comment 21 by, 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, 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, Oct 24 2011
Labels: -Mstone-16 MovedFrom-16 Mstone-17
Comment 24 by, 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.
 Issue 108891  has been merged into this issue.
Comment 26 by, Feb 7 2012
Labels: MovedFrom18 Mstone-19
Comment 27 by, Mar 27 2012
Labels: -Mstone-19 Mstone-20 MovedFrom-19
Comment 28 by, 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, 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, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Any workaround yet ? 
Status: WontFix
createHTMLNotification has been deprecated. Please use the rich notifications API ( for creating notifications. 
Sign in to add a comment