| Issue 31434: | Extensions can focus tabs but not windows | |
| 35 people starred this issue and may be notified of changes. | Back to list |
Google Chrome 4.0.266.0 (Official Build 33992) WebKit 532.6 V8 2.0.3.1 User Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.6 (KHTML, like Gecko) Chrome/4.0.266.0 Safari/532.6 What steps will reproduce the problem? 1. Have an extension call tab.update to select a tab in another window that is either minimized or otherwise not focused. 2. The other window will not focus or restore. 3. Note there is no similar window.update call, no apparent way to focus a window! What is the expected result? Either selecting a tab in another window should focus that window, or, since that is not desirable all the time, there should be a separate API to focus a window. At least, bring it to the top of the Chrome windows, if not the entire desktop (THAT could be annoying in the right cases). What happens instead? Currently, the tab is selected in the window, but the window remains in the background or minimized. If an extension is updating a tab to show the user something the user may not know something has occurred! In my specific case, I am updating my extension One Number to "recycle" tabs... e.g. if the user has Google Reader open the extension will refresh that tab if the user opens Google Reader from my extension instead of making a new tab. If the tab is in another window or minimized there is no way for my extension to indicate something is happening and the user may think One Number is broken. Please provide any additional information below. Attach a screenshot if possible. I can work around this by limiting the "recycle scope" to the current window but it would be nice to be able to do it in all windows.
Comment
1
by
phajdan...@chromium.org,
Jan 11, 2010
Labels: -Area-Undefined Area-Feature Feature-Extensions
,
Jan 13, 2010
(No comment was entered for this change.)
Status: Started
Owner: a...@chromium.org
,
Jan 15, 2010
Issue 20878 has been merged into this issue.
,
Jan 15, 2010
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=36338
------------------------------------------------------------------------
r36338 | aa@chromium.org | 2010-01-15 00:05:14 -0800 (Fri, 15 Jan 2010) | 7 lines
Changed paths:
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_tabs_module.cc?r1=36338&r2=36337
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=36338&r2=36337
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/api/extension_api.json?r1=36338&r2=36337
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/api_test/tabs/basics/test.js?r1=36338&r2=36337
Add the ability to focus a window to chrome.window.update().
Also, enable the tabs api test on linux. I'm probably going
to regret that, but it seems to work with one line removed.
BUG=31434
Review URL: http://codereview.chromium.org/545044
------------------------------------------------------------------------
,
Jan 15, 2010
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=36407
------------------------------------------------------------------------
r36407 | aa@chromium.org | 2010-01-15 13:19:30 -0800 (Fri, 15 Jan 2010) | 4 lines
Changed paths:
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_tabs_module.cc?r1=36407&r2=36406
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=36407&r2=36406
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/api/extension_api.json?r1=36407&r2=36406
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/api_test/tabs/basics/test.js?r1=36407&r2=36406
Re-land r36338: Add the ability to focus a window to chrome.window.update().
BUG=31434
TBR=rafaelw@chromium.org
------------------------------------------------------------------------
,
Jan 21, 2010
Issue 32811 has been merged into this issue.
,
Feb 16, 2010
(No comment was entered for this change.)
Labels: -Area-Feature Area-UI
,
Feb 25, 2010
Any progress on this? To be honest, this is one of the more annoying things that Chrome is lacking (for me). I have a couple extensions that could really use this feature. I understand you guys are very busy, and this isn't a top-priority bug. Just checking that this hasn't been forgotten.
,
Mar 1, 2010
It's in progress. It's been hung up due to some problems with the associated unit tests.
Cc: erik...@chromium.org
,
Apr 12, 2010
We're needing this fix for an internal tool we're trying to build. Is there a good estimate for this fix? Not fixing it might hold us back from an early Dogfood. Please let me know if you'd like me to follow up with more details.
,
Aug 30, 2010
Issue 53521 has been merged into this issue.
,
Sep 28, 2010
It's been 8 months, and the lack of this is causing two annoying usability problems with my extension...
,
Oct 1, 2010
Putting this back on deck for m8.
,
Oct 1, 2010
(No comment was entered for this change.)
Labels: Mstone-8
,
Oct 5, 2010
http://codereview.chromium.org/3584010/show Will this be added to create as well? I'm asking because unlinke update it doesn't require permissions.
,
Oct 5, 2010
chrome.tabs.create({}) creates windows that are focused by default. Do you want to create windows that are _not_ focused?
Also, chrome.tabs.update() doesn't require permissions, just like chrome.tabs.create().
,
Oct 5, 2010
Maybe I misunderstand the term focus, but this is not the case for tabs created from notifications. I filed a bug report on it. http://crbug.com/57826/ And I didn't know update doesn't require permissions any more as well. So I could just focus the tab from the callback function when it is created, all without permissions?
,
Oct 5, 2010
I noticed it doesn't like the previous URL. http://crbug.com/57826
,
Oct 5, 2010
Ah, I've commented on that bug.
Status: Fixed
,
Oct 5, 2010
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=61555
------------------------------------------------------------------------
r61555 | aa@chromium.org | Tue Oct 05 13:41:44 PDT 2010
Changed paths:
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/windows.html?r1=61555&r2=61554&pathrev=61555
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/api/extension_api.json?r1=61555&r2=61554&pathrev=61555
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_tabs_module.cc?r1=61555&r2=61554&pathrev=61555
M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/api_test/tabs/basics/test.js?r1=61555&r2=61554&pathrev=61555
Add chrome.windows.update({focused:true});
BUG=31434
TEST=browser_tests --gtest_filter=ExtensionApiTest.*Tabs
Review URL: http://codereview.chromium.org/3584010
------------------------------------------------------------------------
,
Oct 6, 2010
There is still a slight difference between having focused in chrome.tabs.create (in the case of notifications as mentioned in the bug report) and using chrome.windows.update to focus the window in which the tab was created, because the latter requires permissions. I'm only mentioning it because I like to be as light as possible on requested permissions to avoid scaring users away. Maybe focusing a just created tab from a notification should indeed require permissions. I don't know. I can file a bug report or feature request on it.
,
Oct 6, 2010
Ah, chrome.windows.create/chrome.windows.update still require permissions -- you are right. I was thinking of chrome.tabs.create/chrome.tabs.update. Ok, fair enough. It should be easy to allow those two methods to be used without permissions. I'll look into it.
Status: Started
,
Oct 6, 2010
Thanks!
,
Oct 19, 2010
Since we are passed the branch, moving all mstone-8 issues to mstone-9 for triage/punting
Labels: -Mstone-8 Mstone-9
,
Oct 22, 2010
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.
Labels: Mstone-10
,
Oct 22, 2010
Anthony, please stop. Or at least talk to me first about what you're trying to achieve so that we can work together. This is ridiculous.
Labels: Mstone-9
,
Nov 11, 2010
Thanks for adding this; it's working well for us.
,
Nov 21, 2010
(No comment was entered for this change.)
Labels: Mstone-X
,
Dec 12, 2010
This appears to have been fixed at some point; focusing a tab now brings its window to the front. As far as I'm concerned this bug is fixed. :)
,
May 13, 2011
(No comment was entered for this change.)
Labels: -mstone-x
|
|
| ► Sign in to add a comment |