New issue
Advanced search Search tips
Starred by 41 users
Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug
Team-Security-UX

Blocked on:
issue 472740

Blocking:
issue 392354


Show other hotlists

Hotlists containing this issue:
EnamelAndFriendsFixIt


Sign in to add a comment
Better behavior when waiting for SSL warning interstitial page for same domain in multiple tabs
Project Member Reported by rvargas@chromium.org, Jan 20 2009 Back to list
Chrome Version       : 2.0.157.2
URLs (if applicable) : any https with SSL errors
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: N\A
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Go to a website with SSL errors.
2. Do not proceed to the site.
3. Open a new tab with the same website.

What is the expected result?
The SSL interstitial will be shown.

What happens instead?
There is a "Waiting for cache" message in the 'status bar' and nothing is 
being loaded, until you decide what to do with the other interstitial is 
answered.

This was reported as  bug 4769 , but that one got hijacked by a bug on the 
http cache.

This issue is that the second request is waiting for the first one to 
relinquish exclusive use of the cache entry, and the first one is paused 
waiting for the user. We can give the user a better message in this case.
 
Comment 1 by wtc@chromium.org, Jan 21 2009
Comment 2 by phistuck@gmail.com, Jan 21 2009
Simply showing another interstitial seems fine to me.
(But, when the user proceeds to the site in one of the windows, should it get rid of the 
interstitial of the other window? I guess not, though it would be nice to have an option. 
Like getting rid of SSL errors for certain websites in general (there is an open bug for 
that).)
Comment 3 by darin@chromium.org, Jan 21 2009
Labels: Mstone-2.0
Status: Available
We should try to add a timeout to HttpCache to punt pending transactions to "bypass 
the cache" mode if it appears that things are taking too long.  This should result in 
subsequent tabs also showing the same interstitial error page.
Comment 4 by jon@chromium.org, Apr 3 2009
Labels: JonMoved Mstone-2.1
Moving from milestone 2 to milestone 2.1.
Comment 5 by Deleted ...@, May 5 2009
How about just bypass the cache for the second or later HttpCache::Transaction added
to the same ActiveEntry when the first writer Transaction looks suspended due to some
error? Not perfect solution but may help.
Comment 6 by jon@chromium.org, May 21 2009
Labels: -JonMoved -Mstone-2.1 Mstone-3.0
I don't think this should block 2.1.  Moving to the next release.
Labels: mstone4
Labels: mstone-4
Labels: -mstone4
Labels: -mstone-4 Mstone-5 StopPunting
I'm willing to work on this - I don't have a chromium account yet so not sure how to 
assign it to me.
Comment 12 by wtc@chromium.org, Nov 24 2009
cbentzel: we can't reassign the bug to you either.

tyoshino worked on this bug before.  Here's his changelist:
http://codereview.chromium.org/111005

tyoshino: what's the status of your CL?  Do you mind if
cbentzel takes this bug?
Yes, please go ahead. I don't have time to resume on this. Thanks.
Comment 15 by oritm@chromium.org, Dec 17 2009
Labels: -Area-BrowserBackend Area-Internals
Replacing labels:
   Area-BrowserBackend by Area-Internals

Labels: -Mstone-5 Mstone-6
Punting again...
Comment 17 by wtc@chromium.org, Mar 29 2010
Labels: Internals-Network
Status: Assigned
Labels: -Mstone-6 -StopPunting Mstone-7
Hey Gavin,
Are you still planning on working on this issue?  If not could you flip the status over to "untriaged".  Thanks.

Folks,

I'd like to keep this bug for me & rvargas, but punt it to M8.  Ricardo and I plan on doing a lot of changes to the cache WRT locking, which will no doubt affect this issue.

Is it OK if I retarget this to M8 and work on it concurrently with our cache concurrency project?
Comment 21 by wtc@chromium.org, Aug 25 2010
Labels: -Mstone-7 Mstone-8
Labels: -Mstone-8 Mstone-X
Comment 23 by wtc@chromium.org, Nov 12 2010
 Issue 62491  has been merged into this issue.
 Issue 68616  has been merged into this issue.
BTW, changes on the locking of the cache are tangential to this issue (unless we decide to eliminate the lock).
Comment 26 by wtc@chromium.org, Feb 6 2011
 Issue 63329  has been merged into this issue.
 Issue 86345  has been merged into this issue.
 Issue 39299  has been merged into this issue.
 Issue 106386  has been merged into this issue.
 Issue 79760  has been merged into this issue.
 Issue 119719  has been merged into this issue.
 Issue 134106  has been merged into this issue.
gavin: Are you still working on this? If not, should it be flipped to untriaged, per comment #19?

Cc: gavinp@chromium.org
Owner: ----
Status: Untriaged
It's still on our radar, and this summer we're putting together a cache hit force that might attack it. However, I'll move it untriaged, since noone is working on it specifically now.
Comment 35 by k...@google.com, Jun 25 2012
Labels: -Mstone-X
Status: Available
Comment 36 by sidv@google.com, Jan 8 2013
Ricardo/Gavin  :  what do we need to do to fix this ? It is not a big deal, but it is an annoyance and would be good to fix if we can.. 
This bug is not really about removing the http cache lock, but about letting the user know that there is an interstitial dialog somewhere else.

I think we can detect the condition without much trouble, but then the problem is how to direct the user to the tab that is blocked. Just saying go look for another blocked tab is not very nice. 

Note that just bypassing the cache for new requests will lead to multiple dialogs that are not connected, so the user would have to "fix" the issue n times instead of once.
 Issue 177826  has been merged into this issue.
Comment 39 by joth@chromium.org, Feb 23 2013
IMHO having the user "fix" the problem N times would be better UX than the status quo. (note that a user would solve it less than N times on average, as they might close the tab/tabs/window/browser before some are resolved)

Project Member Comment 40 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network
 Issue 247633  has been merged into this issue.
 Issue 247633  has been merged into this issue.
 Issue 252928  has been merged into this issue.
Comment 44 by jmil...@lbl.gov, Jul 29 2013
Has this issue been solved just yet or is it still being worked on?
Ridiculously, several *years* after being logged, this issue remains open
 Issue 283752  has been merged into this issue.
 Issue 310819  has been merged into this issue.
 Issue 340686  has been merged into this issue.
Time for the 6-monthly compaint that this ticket continues to be back-burnered despite dozens of Dups being merged in with it. There's clearly a problem and no-one is putting this on the "Working" list. Please would someone fix this. It catches me at least once every 2 weeks requiring me to flip through every tab (I'm a HEAVY tab user) to try and find the offending page, every time I restart my browser (because it then forces re-accepting the SSL override)
 Issue 362600  has been merged into this issue.
 Issue 362600  has been merged into this issue.
 Issue 387928  has been merged into this issue.
Project Member Comment 53 by bugdroid1@chromium.org, Jun 24 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8aacaf38e85c45876c72ea77e36ef17e5ab69c26

commit 8aacaf38e85c45876c72ea77e36ef17e5ab69c26
Author: rvargas@chromium.org <rvargas@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Tue Jun 24 05:33:41 2014

Http cache: Implement a timeout for the cache lock.

The cache has a single writer / multiple reader lock to avoid downloading the
same resource n times. However, it is possible to block many tabs on the same
resource, for instance behind an auth dialog.

This CL implements a 20 seconds timeout so that the scenario described in the
bug results in multiple authentication dialogs (one per blocked tab) so the
user can know what to do. It will also help with other cases when the single
writer blocks for a long time.

The timeout is somewhat arbitrary but it should allow medium size resources
to be downloaded before starting another request for the same item. The general
solution of detecting progress and allow readers to start before the writer
finishes should be implemented on another CL.

BUG=6697,  46104 

Review URL: https://codereview.chromium.org/345643003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@279326 0039d316-1c4b-4281-b951-d872f2087c98


Project Member Comment 54 by bugdroid1@chromium.org, Jun 24 2014
------------------------------------------------------------------
r279326 | rvargas@chromium.org | 2014-06-24T05:33:41.209667Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache_transaction.cc?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache_transaction.h?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/mock_http_cache.cc?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/mock_http_cache.h?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache_unittest.cc?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache.cc?r1=279326&r2=279325&pathrev=279326
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache.h?r1=279326&r2=279325&pathrev=279326

Http cache: Implement a timeout for the cache lock.

The cache has a single writer / multiple reader lock to avoid downloading the
same resource n times. However, it is possible to block many tabs on the same
resource, for instance behind an auth dialog.

This CL implements a 20 seconds timeout so that the scenario described in the
bug results in multiple authentication dialogs (one per blocked tab) so the
user can know what to do. It will also help with other cases when the single
writer blocks for a long time.

The timeout is somewhat arbitrary but it should allow medium size resources
to be downloaded before starting another request for the same item. The general
solution of detecting progress and allow readers to start before the writer
finishes should be implemented on another CL.

BUG=6697,  46104 

Review URL: https://codereview.chromium.org/345643003
-----------------------------------------------------------------
Comment 55 by phistuck@gmail.com, Jun 24 2014
20 seconds are a very, very long time for the user to get stuck.
I should never wait for the cache, I should wait for the network instead (this has the benefit of surely getting fresh content).
If you do not even begin getting something from the cache in five seconds, I would suggest you hit the network. At least on desktop, perhaps the mobile situation is a bit more metered and may be expensive.

A better way (if possible, or perhaps the occupied reader is still at fault here) would be to know whether the cached resource is big. If it is, wait 20 seconds until you start receiving it. If it is not (say, less than 1 MB), just fetch it from the network if five seconds have passed.
Cc: jcivelli@chromium.org davidben@chromium.org creis@chromium.org f...@chromium.org
 Issue 222344  has been merged into this issue.
Comment 57 by f...@chromium.org, Jul 23 2014
Blocking: chromium:392354
Cc: ranjitkan@chromium.org
 Issue 411089  has been merged into this issue.
Comment 59 by f...@chromium.org, Sep 18 2014
Labels: Cr-Security-UX
Cc: palmer@chromium.org
Labels: Cr-Internals-Network-Cache Cr-Internals-Network-SSL Cr-Security
Summary: Better behavior when waiting for SSL warning interstitial page for same domain in multiple tabs (was: Better message when waiting for ssl interstitial page.)
Current status: Instead of saying "Waiting for cache" message in the Status Bar, it now says nothing, and then after a few seconds manages to load the interstitial.

(I figure it's probably still trying to write "Waiting for cache" in the Status Bar, but a not-fully-loaded page has no Status Bar yet, so...)

Suggested solutions (in no particular order):

* Close the tab, then focus the tab that has the interstitial in it.

* Focus the tab that has the interstitial in it. When/if the user finally does click through the interstitial in the 1st tab for that domain, load the domain in the other tab(s) that were waiting.

* Don't wait on the HTTP cache; just load the interstitial immediately. (I.e. no need to wait for a cache time-out if we know the domain can't load yet.)
Comment 61 by creis@chromium.org, Sep 18 2014
@comment 60:  #3 sounds like the best if there's some way to know to trigger the interstitial.  At the moment, the logic that would show the interstitial is never reached because the loader is blocked in an earlier state.  #2 sounds like a reasonable workaround in the meantime, which only requires bringing a tab to the front.  Both approaches require detecting the issue, though.  Someone from the loader team might have ideas how to do that.

(#1 is destructive and loses the user's back/forward history, so I wouldn't recommend it.)
Comment 62 by laforge@google.com, Apr 28 2015
Cc: -wtc@chromium.org
Comment 63 by b...@chromium.org, May 6 2015
Labels: -Cr-Internals
So, we have the fix in #54; is that the most we can do? Does anyone want to try to take on 1 of the approaches in #60? Otherwise, maybe we should just mark this as Fixed or Archived?
Labels: -Cr-Internals-Network Cr-Internals-Network-HTTP
I agree with creis that #1 seems inherently bad. #2/#3 requires knowing about the issue before-hand, and neither the loader nor the network stack know this. You could roughly approximate things at the loader layer once it's dispatched an interstitial, but there are some sharp corner cases that it'd improperly detect.

I don't think it's intrinsically wrong to keep open - it's enough that it trips people up (so it helps to be searchable and dupe-able), and it is an open issue if someone wants to tackle it.
If nothing else, we should keep this open as one of many many things that will get resolved if we some day fix the darn cache lock.
Cc: -rvargas@chromium.org
Blockedon: chromium:472740
Project Member Comment 69 by sheriffbot@chromium.org, Jun 18 2016
Labels: Hotlist-OpenBugWithCL
A change has landed for this issue, but it's been open for over 6 months. Please review and close it if applicable. If this issue should remain open, remove the "Hotlist-OpenBugWithCL" label. If no action is taken, it will be archived in 30 days.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Hotlist-OpenBugWithCL
This is still a problem with the cache lock.
Labels: Interstitials
Components: -Security>UX UI>Browser>Interstitials
Labels: -Interstitials
Labels: Hotlist-EnamelAndFriendsFixIt
Sign in to add a comment