My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 456: Javascript alerts are modal to Chrome UI, not to individual tab.
298 people starred this issue and may be notified of changes. Back to list
Status:  Available
Owner:  ----
Cc:  darin@chromium.org, ben@chromium.org, skuhne@chromium.org, stro...@chromium.org, vkomond...@chromium.org, zelidrag@chromium.org

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
 
Reported by rtshils...@gmail.com, Sep 3, 2008
Product Version      : 0.2.149.27
URLs (if applicable) : http://www.javascripter.net/faq/confirm.htm
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: UNTESTED
    Firefox 3: FAIL
         IE 7: FAIL

What steps will reproduce the problem?
1. Go to http://www.javascripter.net/faq/confirm.htm
2. Imagine that this is a nasty website that you wish to terminate without 
clicking either button
3. Try to close the current browser tab

What is the expected result?
Tab can be killed.  The cartoon says that each tab is a separate process, 
which can be independantly closed if the user wishes. 

What happens instead?
The dialog is modal across the entire browser, rendering the entire Chrome 
session unusable until either OK or Cancel is clicked.  It is not possible 
to close the offending tab.

Please provide any additional information below. Attach a screenshot if 
possible.

A similar situation is described at http://saalwaechter-
notes.blogspot.com/2008/02/javascript-alertconfirm-trap.html
 
Sep 4, 2008
#1 pall...@gmail.com
+1

Opera 9: JavaScript can be disabled in the alert dialog.
Sep 5, 2008
#2 llager...@gmail.com
Yes, i confirm this browser problem. The javascript alert() dialog cannot be modal 
for the entire chrome. Must be modal just by the tab that call it, and the tab MUST 
accept be closed with the alert on screen.
Sep 6, 2008
#3 ben@chromium.org
Various technical limitations led to this unfortunate detail :-/

Darin thinks this problem can be solved now however, so I imagine this will be 
completed in a future release.
Status: Untriaged
Labels: -Area-Unknown Area-BrowserUI
Sep 12, 2008
#4 Hunn...@gmail.com
+4
This has been a major annoyance ever since Tabbed browsers came to be, and it pains 
me nobody has dealt with this by making alerts "stick" to their parent tab.

I'd have thought Mozilla would have done this, seeing as they created some internal 
elements and attributes for Firefox. 




Oct 2, 2008
#5 ben@chromium.org
(No comment was entered for this change.)
Oct 3, 2008
#6 nicolas....@gmail.com
Star the issue instead of saying +1
Oct 21, 2008
#7 mal.chromium@gmail.com
(No comment was entered for this change.)
Status: Assigned
Owner: da...@chromium.org
Labels: Mstone-X
Nov 20, 2008
#8 ydf...@gmail.com
This is also problem for other Chrome windows. The alert box is modal for tabs in 
other Chrome windows.

I'm not sure how useful this dual view bookmarklet is with this issue.
http://www.chromeplugins.org/plugins/google-chrome-dual-view/).
Dec 31, 2008
#9 suna...@chromium.org
 Issue 5813  has been merged into this issue.
Dec 31, 2008
#10 suna...@chromium.org
 Issue 3658  has been merged into this issue.
Feb 15, 2009
#11 t.broyer
Note that authentication boxes have the expected behavior: you can switch from tab to 
tab (including using the keyboard) and close the tab (including with the keyboard) 
without the need to dismiss the dialog box first.

To reproduce, open https://chromium.googlecode.com/svn/ in another tab and start 
playing around.
Mar 27, 2009
#12 phajdan.jr@chromium.org
 Issue 4455  has been merged into this issue.
May 31, 2009
#13 ecr...@gmail.com
Just like the authentication boxes, the Javascript alerts should only effect the 
viewing area on a single tab, not an entire tab. No Javascript alert should stop the 
user accessing the bookmark tool bar or address bar.
May 31, 2009
#14 phistuck
How about making it modal to the tab and also - make the tab blink (or whatever) whenever 
there is an open alert\confirm\prompt box while it is not focused (like Windows does in the 
taskbar)?
I think this is pretty logical.
Jun 16, 2009
#15 vir...@gmail.com
But what about a cross-pages application which use window.open function to maintain 
parent-chind windows relationship, the developer may need to block them all when an 
alert box show up.
Jun 16, 2009
#16 phistuck
No, that is bad development of web pages.
You always could close the opened window (as long as it is not a tab in that window) 
while its opener shows an alert box, in any browser (as far as I remember).


Wow, I just noticed that the whole browser is hung until you close that alert box, that is 
bad, bad, bad. :|
Jul 5, 2009
#17 kekn...@gmail.com
Semi-DoS based on this, as the option to ban javascript popups is forgotten on a page 
reload:

<script>
setTimeout("location.reload();",1);
alert('DoS');
</script>

You can still manage to close the window with good coordination of Enter + middle-
clicking or Click + Ctrl-W, but the window is only a few tens of milliseconds wide.

It's a DoS for the average user.
Jul 9, 2009
#18 synet...@gmail.com
I can’t help but notice that this is still an issue with 3.0.193.0 (20196). What’s more 
is that the similar—at least from a user perspective—proxy authentication dialog ( Issue 
13213 ) is modal only to the associated tab as expected.

Jul 15, 2009
#19 adys...@gmail.com
FWIW, an additional "Prevent this webpage from creating new dialogs" has been 
implemented. 
Oct 30, 2009
#20 est...@chromium.org
 Issue 26361  has been merged into this issue.
Dec 14, 2009
#21 nbur...@gmail.com
Here is a example of intentional misuse of this behavior:

http://www.google.com/search?rlz=1C1GGLS_enUS312US312&sourceid=chrome&ie=UTF-8&q=360'+camera

It creates a browser modal dialog box that acts as a modal pop-up advertisement.  I
have encountered several sites like this over the past few months. One of them looped
infinitely with a dialog, new window, and dialog cycle.

I'm not sure how things stand these days, but some browsers have given elevated
rights for actions that the user initiated with a click.  To be safe, I avoid
interacting with questionable pop up dialogs and I watch the URLs behind links if I'm
not sure what a page is up to.  That makes these browser modal dialog boxes quite
irritating.
Dec 18, 2009
#22 or...@chromium.org
Area-UI-Features label replaces Area-BrowserUI label
Labels: -Area-BrowserUI Area-UI-Features
Jan 3, 2010
#23 jordonwii
I noticed Opera is implementing tab-modal alert boxes in Opera 10.5.  
Chrome should do something similar.
Jan 4, 2010
#24 fam....@live.nl
OpenFileDialogs and SaveFileDialogs also have this non-tab-specific behaviour and 
should also be tab-modal. Not only the JavaScript alerts
Jan 4, 2010
#25 ecr...@gmail.com
If chrome goes to this extent (which I hope it does) it would be nice if there a 
graphical way to know that a tab is showing a dialog / blocked.

Currently the HTTP basic authentication dialog is modal per tab, but the tab still 
looks like it is loading (with the circular loading image in place of the favicon on 
the tab moving anti-clockwise).

If more tab-modal dialogs like this are used in chrome, the user should be alerted. 
Some ways to show a tab-modal dialog is showing on another tab could be:
 - Yellow Tab
 - Stop loading... circular motion
 - Replace loading... circular motion with gently pulsing circle (making sure it does 
not distract the user)
 - Change the text on the tab to that of the modal dialog

Please at least change something making sure it does not stand out. If you are 
waiting for dialogs to show on 20 different tabs (HTTP Auth / Javascript or other), 
don't make me check every tab for dialogs. 
Jan 4, 2010
#26 zelidrag@chromium.org
(No comment was entered for this change.)
Owner: zelid...@chromium.org
Cc: da...@chromium.org b...@chromium.org
Jan 4, 2010
#27 thakis@chromium.org
zelidrag: If you're doing something here, talk to viettrungluu@chromium.org ( trungl on 
irc, http://codereview.chromium.org/459008/show ) first.
Jan 12, 2010
#28 nbur...@gmail.com
I just encountered a site that uses this feature to attack the user.  The site pretends 
to be a windows update / security application running on the user's local machine.  It 
spoofs the look of windows XP and pops up windows that look like system prompts.  When 
you attempt to close the window the page pops up another modal dialog box, and when you 
click to close the modal dialog box it begins a download.

http://20-onlinescanner.com/s1/?
pid=p2Ty0jzwMy0yJmlwPTE3NC4zNC4yMjIuNzEmdGltZT0xMjYxMYAMPQVM
Jan 15, 2010
#29 bugdroid1@gmail.com
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=36415 

------------------------------------------------------------------------
r36415 | zelidrag@google.com | 2010-01-15 13:49:44 -0800 (Fri, 15 Jan 2010) | 12 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/browser.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/browser.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/browser_window_controller.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/browser_window_controller.mm?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/constrained_window_mac.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/constrained_window_mac.mm?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/tab_strip_controller.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/tab_strip_controller.mm?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/constrained_window_gtk.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/constrained_window_gtk.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/tabs/tab_renderer_gtk.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/tabs/tab_renderer_gtk.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/tabs/tab_strip_gtk.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/gtk/tabs/tab_strip_gtk.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/login_prompt_gtk.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/login_prompt_win.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_view_host.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_view_host.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_view_host_delegate.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/constrained_window.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents_delegate.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents_view_gtk.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents_view_gtk.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/constrained_window_win.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/constrained_window_win.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/login_view.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/login_view.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_renderer.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_renderer.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_strip.cc?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab_strip.h?r1=36415&r2=36414
   M http://src.chromium.org/viewvc/chrome/trunk/src/views/view.cc?r1=36415&r2=36414

Tab-modal dialog improvements:
- treat constrained dialogs as tab-modal - only one shows at the time
- added visual indication (tab pulsing) to the tab strip when a tab is blocked by a tab-modal dialog
- blocked all UI activity from rendrer host and forced refocusing on constrained (tab-modal) dialogs

This CL reverts http://codereview.chromium.org/384113 and instead incorporates the changes from http://codereview.chromium.org/392018.


BUG=456,27585,27620
TEST=Go to http://www/~thakis/cgi-bin/test.html hit esc.

Review URL: http://codereview.chromium.org/541056
------------------------------------------------------------------------

Jan 19, 2010
#30 lafo...@chromium.org
 Issue 31377  has been merged into this issue.
Feb 6, 2010
#31 prog...@gmail.com
please also take a look at Issue 3531 to see if it is a duplicate (it has a testcase)
Feb 17, 2010
#32 lafo...@chromium.org
(No comment was entered for this change.)
Labels: Area-UI
Feb 17, 2010
#33 lafo...@chromium.org
(No comment was entered for this change.)
Labels: -Area-UI-Features
Apr 9, 2010
#34 geki...@gmail.com
I think the javascript alert should be the same as the new "Confirm Form Resubmission" 
dialog.
Test it:
Open more tabs in one tab open:
http://hroch486.icpf.cas.cz/formpost.html
Submit something and then press reload page -> see the dialog -> it's not modal, you 
can change the tab

Confirm Form Resubmission.png
57.1 KB   View   Download
May 8, 2010
#35 rene.su...@gmail.com
When you get redirected to a website that displays a fake "malware detected" Javascript 
alert, on Firefox, you can click on the options and turn on Javascript.

In Chrome, the Javascript alert is modal so you cannot turn off Javascript to prevent 
any further Javascript from running.

I believe you should be able to turn off Javascript when one of these sites displays a 
Javascript alert.
May 8, 2010
#36 jordonwii
@rene.sugar: You know that if a website displays more than one alert box, a checkbox 
appears to disable further alert boxes from that website, right?
May 8, 2010
#37 phistuck
@jordonwii That is correct, but the JavaScript will still keep on executing, it does 
not have to show alert boxes, it can simply keep running and you might just want to 
turn it off.
This is a good argument, in my opinion.
Jul 13, 2010
#38 stuartmorgan@chromium.org
 Issue 48961  has been merged into this issue.
Jul 17, 2010
#39 Nazg...@gmail.com
This has already been solved by the niceAlert extension; The real problem is doing the same with prompts.
I believe it should have the same look and feel as the 'Chrome crashed. Restore?' prompt.
Oct 5, 2010
#40 Ynki1...@gmail.com
Are you guys even gonna properly fix this issue. It's been 2 years, come on, I was struct with this problem on numerous occasions, and am baffled as to why the alert dialog is left modal for the entire application, not even allowing you to close the tab.
Oct 31, 2010
#41 temp01...@gmail.com
 Issue 61369  has been merged into this issue.
Oct 31, 2010
#42 Kurtextrem
Yeah. In Chrome Youtube Video it says all are not modal.. whats now? It is...
Oct 31, 2010
#44 k...@kenman.net
+1 (I don't care what the help text says)
Nov 10, 2010
#46 ryazanov
 Issue 62661  has been merged into this issue.
Nov 16, 2010
#47 Andy.R.S...@gmail.com
This issue not only affects the current window, but ALL windows.  An open alert prevents interaction, closure, or even viewing, on other windows.
Dec 14, 2010
#48 lealcy
This discussion is still in place? Appears this is a really challenging change in the chromiums code. And it is still plain annoying for me that a simple dialog box freeze the entire browser. I hope you guys improve it soon. Cheers.
Dec 23, 2010
#49 priyajeet
Since Chrome doesn't make modal popups via showModalDialog actually modal to the tab it was launched from, it also causes a browser freeze if a person accidentally minimized a modal popup. While you can work on the main page, navigating away from that page due to some action is all blocked out till that modal popup is closed.

This should be changed, if the popup is not modal then it should not freeze out the main window. Or if there is a modal popup open, some indication on the main page would be nice to alert or nudge the user not to ignore the modal popup.


https://code.google.com/p/chromium/issues/detail?id=16045
Mar 4, 2011
#50 priyajeet
In case folks haven't noticed, Firefox 4 alerts/confirms are coming up with an underlay now and the alert popup seems html based (can't inspect it so unsure). Also the alerts/confirms are confined to the tab now.

It would be nice for chrome to also go down this route and make the alerts identical to the DOMUI-Settings modal box that we see with a -webkit-radial-gradiant() eg: Clear Browsing Data
Screen shot 2011-03-04 at 7.23.16 PM.png
194 KB   View   Download
Mar 6, 2011
#51 mkte...@gmail.com
All I know is when I click "Download" at Mediafire, I often get a popup ad that spawns a Javascript alert, preventing me from closing the parent ad directly.  It's infuriating.

Actually, even with popups that don't pull that trick, the Save dialog itself has a similar effect (as comment 24 mentioned): If I'm a bit too slow, it appears and blocks me from closing the ad popup until I finish picking my download location like a good boy.
Apr 6, 2011
#52 steven.s...@gmail.com
Locking of the entire app on a modal dialog is the *desired* effect by those programming malicious applications.

Since as a user, I hate any time that someone tries to lock up the UI when I am browsing and I consider this to be a primary indicator of malicious intent, how about considering a preferences option that if a page tries to invoke this function, the browser takes over and asks if I would like to close this offending tab.

Apr 6, 2011
#53 MALfunct...@gmail.com
@52, the browser already offers to block further dialogs on the page.
Apr 6, 2011
#54 steven.s...@gmail.com
Perhaps that is too late.

Suppose I am browsing to an unknown site. The page is compromised and
the first thing it does is lock up the UI with a dialog box. I am not
sure what will happen on any user input because I know that I am under
attack.

Right now, what I usually do is open a text terminal and do a pkill on Chromium.
Apr 6, 2011
#55 dherber...@gmail.com
@54 It's never "too late" to block further dialogs. The option is included directly in the alert. No need to kill the process.
Apr 6, 2011
#56 k...@kenman.net
@55 I think he is saying (and please correct me if I'm wrong), that once he gets the initial UI lock, he wishes to halt *any* further script processing since he has very good reason to believe that any further scripting would be malicious. If the dialog wasn't modal, he could simply close the tab (which would of course halt further script processing); but, it IS modal, and so clicking "ok" (or whatever is appropriate) on the dialog *must* be done in order to be able to close the tab, but which will also let the page continue to execute script starting from the moment that the dialog is closed. This is what is meant by "too late".
Apr 6, 2011
#57 MattSo...@gmail.com
@55 As far as I know, the option to block further dialogs is not included in the first dialog (only the second, third, etc.).

Another example of when this would be useful: say a webpage pops up a prompt, where I have to enter some text.  However, what I need to enter is a long confirmation code.  I didn't copy it to the clipboard (because I didn't know I would need it), but this pop-up comes up, so I try to switch to another tab to retrieve it.  But I can't switch to the other tab, so I have to close the prompt, and who knows what effect that has on the page's JavaScript.
Apr 6, 2011
#58 cor...@aldomx.com
Blocking dialogs won't help you to stop this malicious code :)

var counter = {divs:1,spans:1};
while(counter.divs || counter.spans)
{
  if( confirm("Hello I'm a malicious code which will insert a DOM Element regardless your coice.") )
  {
    $("body").append("<div>Malicious div #"+counter.divs+"</div>");
    counter.divs++;
  }
  else
  {
    $("body").append("<span>Malicious span #"+counter.spans+"</span>");
    counter.spans++;
  }
}

Having confirms/promts/alerts/onbeforeunload/whatever else modal to individual tabs are better so if you find something suspicious you can simply close the offending tab and prevent the malicious code to be executed.
Apr 6, 2011
#59 MALfunct...@gmail.com
If you want to close the tab upon seeing a dialog, the resolution of this issue should allow that.
Apr 6, 2011
#60 jordonwii
But why would any malicious website throw up an alert box?  Looking at the code in #58, the confirm box is completely unnecessary...

However, it does seem awful barbaric to have alert/confirm boxes cause 100% browser lockup, especially for instances like #57.
Apr 6, 2011
#61 Kurtextrem
@all check this http://optimalcycling.com/other-projects/browser-security-tests/ it comes again, and again, ... and... again! I think this is what @54 mean
Apr 6, 2011
#62 jordonwii
@61: That's interesting.  As a side note, I got it to stop by checking "Disable alert boxes" and then hitting "Cancel".
Apr 6, 2011
#63 k...@kenman.net
@62 It doesn't halt script execution, though, which is the crux of the problem.
Apr 6, 2011
#64 cor...@aldomx.com
@60 Have you seen recent advertising from malicious sites which prompts you to register at groupon?

Its something like:

confirm: "this is your great chance to get coupons blah blah blah..."
*creates an ad*
confirm: "are you sure you want to miss this chance blah blah blah..."
*creates another ad*
confirm: "this is a once-in-a-life opportunity, do you really really want to miss it blah blah blah"
*creates even another ad*
onbeforeunload: "this is your last chance to get this offer..."
*fires click() to an ad and closes*

IIRC megaupload has them
Apr 6, 2011
#65 lealcy
Three and a half year of discussions just to not correct this bad design decision of let dialog boxes hang up the browser (inherited from another browsers).

Just copy the Firefox solution.
Apr 6, 2011
#66 perq87
There's already implemented solution exists in this project. Chrome uses non-modal dialogs for authentication dialogs and form resubmission confirms. Maybe it would be harder to implement. I understand that alert calls come from javascript engine but this is against Google Chrome's design (Tab seperation, security, bla bla). Also you (Google) did V8 too :)
Apr 6, 2011
#67 darin@chromium.org
There are too many unhelpful comments in this bug, so I'm restricting comments to committers.

Let me summarize my position.  There are trade-offs here.  Both Mozilla and Opera have implemented tab modal dialogs in a way that have really bazaar side-effects, which cannot be avoided.  They cause developers to have to deal with re-entrancy in their code, and they can cause strange problems if multiples tabs spawn dialogs.  I also think it is a shame that they made these changes as it seemingly reduces the incentives for us as browser vendors to invent a better, asynchronous API for input-modal dialogs.

We have chosen not to go with their solution because we favor stability and sanity for web developers.
Labels: Restrict-AddIssueComment-Commit
Aug 7, 2011
#68 mkte...@gmail.com
 Issue 91938  has been merged into this issue.
Nov 3, 2011
#69 thestig@chromium.org
 Issue 98486  has been merged into this issue.
Feb 24, 2012
#70 glen@chromium.org
 Issue 114819  has been merged into this issue.
Sep 12, 2012
#71 glen@chromium.org
 Issue 148591  has been merged into this issue.
Cc: skuhne@chromium.org
Dec 17, 2012
#72 jeffr...@google.com
(No comment was entered for this change.)
Cc: jeffr...@chromium.org
Dec 17, 2012
#73 stro...@chromium.org
(No comment was entered for this change.)
Cc: stro...@chromium.org
Mar 10, 2013
#74 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-UI Cr-UI
Mar 13, 2013
#75 lafo...@google.com
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Jul 24, 2013
#76 lafo...@google.com
(No comment was entered for this change.)
Cc: -jeffr...@chromium.org
Oct 28, 2013
#77 thestig@chromium.org
 Issue 311568  has been merged into this issue.
Feb 10, 2014
#78 abodenha@chromium.org
 Issue 342421  has been merged into this issue.
Cc: vkomond...@chromium.org
Jun 11, 2014
#79 phist...@chromium.org
Looks like no one is working on this. Changing the status and removing the owner.
Status: Available
Owner: ---
Cc: zelidrag@chromium.org
Labels: -Mstone-X
Jun 11, 2014
#80 phist...@chromium.org
 Issue 142079  has been merged into this issue.
Sign in to add a comment

Powered by Google Project Hosting