424689 - gmail (v2) is openened unsecured after session restore

Status: RESOLVED FIXED

(Firefox :: Session Restore, defect)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032306 Minefield/3.0b5pre ID:2008032306

repro:
Open FF
Open gmail
in Options -> Main set [Show my windows and tabs from last time]
Close FF
Open FF after a minute or so

result:
Gmail is opened, but with white background in the locationbar and a warning ! on the lock icon in the statusbar.
It's not 100% reproducable, but fails at least 9 out of 10 times

I don't think this is a regression, it has always been like this since session restore.

My bad not to file this bug before.

Comment 1

[Simon Bünzli]

That's actually a subtlety on Gmail's side: If you start from http://mail.google.com, then you'll get an insecure http-connection after you've been logged in, whereas when you start from https://mail.google.com (note the _s_) then the connection remains secured even afterwards.

So unless I'm missing something, this is WORKSFORME.

Comment 2

[Peter van der Woude [:Peter6]]

yeah, my stupidity, typing the wrong url .
the bug still stands though.
 

Comment 3

[Ryan VanderMeulen [:RyanVM]]

I can definitely reproduce

Comment 4

[Simon Bünzli]

Could you please upload your sessionstore.js after you've closed Firefox with Gmail open for further debugging?

For privacy reasons, make sure to do this in a new window and close all other windows first, so that only the Gmail related URLs are included (which AFAICT are session specific and will expire as soon as you restart and log out). Alternatively you could try inspecting sessionstore.js yourself (looking for http:// URLs within Gmail's https:// ones) or e-mail me the file directly.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Attachment: sessionstore.js showing the problem

I just reproduced the bug with this sessionstore.js. FYI, reloading GMail brings back the yellow bar most of the time, but on occasion I've had to do so twice before it would go yellow again.

Comment 6

[Simon Bünzli]

Thanks, Ryan, now I can reproduce this as well. This happens only when using Gmail v2 (which isn't available in all languages yet) where, although we correctly restore only https URLs somehow unencrypted content gets involved.

My guess would be that this is due to us not correctly restoring frame names (bug 403179). Will have to go inspecting Gmail with DOMi when I've got some more time at hand to verify that theory, though...

Comment 7

[Peter van der Woude [:Peter6]]

note: a soft reload still makes it fail (most of the time), you'll need a hard reload (ctrl+F5) to get the secure version again.

Comment 8

[Simon Bünzli]

One further StR that's missing from comment #0: Set the hidden pref browser.sessionstore.privacy_level to 0. Otherwise Gmail will just ask you to log in again after the restart. As a consequence this bug shouldn't block Firefox 3.0.

BTW: Using DOMi, I didn't find any insecure files loaded into Gmail. And we'd first have to know what's actually going on...

Comment 9

[Peter van der Woude [:Peter6]]

my browser.sessionstore.privacy_level = 1 , which wasn't hidden and is default afaik.
(i never touched it)

Comment 10

[Simon Bünzli]

Peter: Does this happen on a clean profile, as well? I have to re-login whenever the cookies are deleted (which they are with browser.sessionstore.privacy_level==1).

Comment 11

[Peter van der Woude [:Peter6]]

Simon, on exit i only clear the following privacy data:
-  saved form and search history
-  authenticated sessions

this also happens with a clean profile with above mentioned changes applied

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

This feels like it falls into a more general "we should be serializing and restoring the entire DOM state" bucket, which we can't really block on.

Comment 13

[Simon Bünzli]

Peter: Have you ever experience this bug again? I used to be able to reproduce this issue back in March but no longer am. Looks like Google fixed the issue on their end (which'd make this WORKSFORME).

Comment 14

[Simon Bünzli]

Never mind. I think I've found the culprit: wyciwyg URLs. See bug 450595 comment #10 for a possible patch.

Comment 15

[Simon Bünzli]

Fixed by bug 450595.