Gmail (https-only) won't properly load

VERIFIED FIXED in mozilla1.8.1beta2

Status

()

Core
DOM
P1
major
VERIFIED FIXED
12 years ago
11 years ago

People

(Reporter: Peter6, Assigned: mrbkap)

Tracking

({fixed1.8.0.7, fixed1.8.1, regression})

Trunk
mozilla1.8.1beta2
fixed1.8.0.7, fixed1.8.1, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1 +
blocking1.8.0.4 -
blocking1.8.0.5 -
blocking1.8.0.7 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: regression from 321299 (fix incorporated into 321299 branch patch), URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060411 Firefox/3.0a1 ID:2006041111 [both Cairo and non-Cairo]

repro:
1.Open FF
2.Open Gmail

result:
-sometimes you're stuck on a blank page
-sometimes the main window loads but all links are dead
-sometimes it works

also happens in -safe-mode

reproducable: not all the time

regressionwindow:
works in 20060410 nightly
fails in 20060411 nightly
(Reporter)

Comment 1

12 years ago
actually, the links do work... the screen simply refuses to refresh.
nothing in the errorconsole
I saw this yesterday with the 2006-04-11 Mac (PPC) nightly (but not with a 2006041012 build).
OS: Windows 2000 → All
Hardware: PC → All

Comment 3

12 years ago
Are you using http or https?

(Reporter)

Comment 4

12 years ago
(In reply to comment #3)
> Are you using http or https?
> 
allways https
(Reporter)

Comment 5

12 years ago
in http it seems fine (but i dont consider that an acceptable workaround)

Comment 6

12 years ago
Agreed, but it helps to describe the actual problem better :)
(Reporter)

Updated

12 years ago
Flags: blocking1.9a1?
Summary: Gmail won't properly load → Gmail (https-only) won't properly load
(Reporter)

Comment 7

12 years ago
regressionwindow:

works in 20060410 2021pdt build
fails in 20060411 0602pdt build

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-04-10+19%3A35%3A00&maxdate=2006-04-11+06%3A02%3A00&cvsroot=%2Fcvsroot

bug 321299 , Boris ?



No idea.  Ask in that bug?  I wonder why (or whether) we're even hitting that code here.
(Reporter)

Comment 9

12 years ago
(In reply to comment #8)
> No idea.  Ask in that bug? 

I can't , it's a security_group-only bug
Blocks: 321299

Updated

12 years ago
(Assignee)

Comment 10

12 years ago
I'm on this. It is indeed a regression from bug 321299. In particular, the problem is that the scope object introduced by that bug was assumed (and enforced) to be immutable once set, and document.open breaks that assumption. The fix is to make the scope object mutable, but this involves reparenting all of the wrappers in the old scope.
Assignee: nobody → mrbkap
Component: General → DOM
Flags: blocking1.8.0.3?
Flags: blocking-aviary1.0.9?
Priority: -- → P1
Product: Firefox → Core
Whiteboard: regression from 321299
Target Milestone: --- → mozilla1.9alpha
(Assignee)

Updated

12 years ago
Flags: blocking1.7.14?
Hmm... do we really want to make document.open give a new inner window?  I guess that's safer then clearing scope on the old one etc.... :(

Comment 12

12 years ago
I'm curious why this only affects https Gmail, and I'm curious what a reduced testcase would look like.
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 13

12 years ago
Created attachment 218364 [details] [diff] [review]
Partial fix

This is not the final patch. I know of two problems with it (though I wouldn't be too surprised if there were more problems):
-- ReparentAllWrappersInScope is a misnomer for the new function, it should be named something like ReparentAllUniqueWrappersInScope.

-- I currently assert due to a "potential deadlock" while rewrapping wrappers. I'm still trying to figure out why.
(Reporter)

Comment 14

12 years ago
strange enough, Gmail works with a cairo build and http, but not with a non-cairo build and http
(Assignee)

Comment 15

12 years ago
fwiw, I don't seem to be able to reproduce the assertion anymore.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060416 Firefox/3.0a1
Still fails with the very last hourly.
Sometimes it works in a certain tab for some time, but when you open a new tab it fails again. When it fails it goes on failing. Right now I have one Gmail tab open that works (how long?) and four other dead ones.
You can only rely on 1.5x at the moment for Gmail.
Plussing for 1.8.0.3 so we don't forget in case we take 321299
Flags: blocking1.8.0.3? → blocking1.8.0.3+
*** Bug 334475 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 19

12 years ago
Comment on attachment 218364 [details] [diff] [review]
Partial fix

I'm going to try to make a patch that avoids the nested locking. This is basically ready for review anyway, though.
Attachment #218364 - Attachment is obsolete: true
This just happened to me with non-https gmail. So I guess it's a timing issue that is just much more likely to happen with https, for whatever reason.
(Reporter)

Comment 21

12 years ago
(In reply to comment #20)
> This just happened to me with non-https gmail. So I guess it's a timing issue
> that is just much more likely to happen with https, for whatever reason.
> 

Yeah, same here (it has been like that from the start), but maybe in just 5% of all cases while on https it's 100% of the time.
Sometimes I get slow script warnings.
(Reporter)

Comment 23

12 years ago
(In reply to comment #22)
> Sometimes I get slow script warnings.
> 
at least 50% of the time on https, almost never on http
(Assignee)

Comment 24

12 years ago
Comment on attachment 218364 [details] [diff] [review]
Partial fix

Actually, avoiding the locking isn't as feasable as I'd hoped.
Attachment #218364 - Attachment is obsolete: false
Attachment #218364 - Flags: superreview?(jst)
Attachment #218364 - Flags: review?(jst)

Comment 25

12 years ago
*** Bug 334840 has been marked as a duplicate of this bug. ***
How is this bug coming, is it feasible to fix for 1.8.0.3? Sounds like it's stalled.
Comment on attachment 218364 [details] [diff] [review]
Partial fix

r+sr=jst
Attachment #218364 - Flags: superreview?(jst)
Attachment #218364 - Flags: superreview+
Attachment #218364 - Flags: review?(jst)
Attachment #218364 - Flags: review+
(Assignee)

Comment 28

12 years ago
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Great! Very welcome patch.
> Fix checked into trunk.

I believe this broke the trunk.(In reply to comment #28)
(Reporter)

Comment 31

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060426 Minefield/3.0a1 ID:2006042613 [cairo]

verified fixed, thanks

Comment 32

12 years ago
(In reply to comment #28)
> Fix checked into trunk.
> 

Thanks!   Working like a charm!  And at the same time, gmail's design has changed...just a coincidence.

Updated

12 years ago
Attachment #218364 - Flags: approval1.8.0.4?
Verified FIXED using 04-27-16 build of SeaMonkey trunk on Windows XP.
Status: RESOLVED → VERIFIED
Depends on: 335785
Might be worth taking the patch to bug 335785 as well so this doesn't introduce a leak.
Comment on attachment 218364 [details] [diff] [review]
Partial fix

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #218364 - Flags: approval1.8.0.4? → approval1.8.0.4+
Attachment #218364 - Flags: approval-branch-1.8.1+
Flags: blocking1.8.0.5?
Flags: blocking1.8.0.4-
Flags: blocking1.8.0.4+
Comment on attachment 218364 [details] [diff] [review]
Partial fix

Unapproving for 1.8.0.4 and moving to next release per bug 321299 comment 36
Attachment #218364 - Flags: approval1.8.0.5?
Attachment #218364 - Flags: approval1.8.0.4-
Attachment #218364 - Flags: approval1.8.0.4+
Attachment #218364 - Flags: approval-branch-1.8.1?
Attachment #218364 - Flags: approval-branch-1.8.1+
Flags: blocking1.8.0.5? → blocking1.8.0.5+
Comment on attachment 218364 [details] [diff] [review]
Partial fix

Jonas says we'll get a combined branch patch for all the related regressions.
Attachment #218364 - Flags: approval1.8.0.5?
Attachment #218364 - Flags: approval1.8.0.5-
Attachment #218364 - Flags: approval-branch-1.8.1?
Attachment #218364 - Flags: approval-branch-1.8.1-
Moving to 1.8.0.6 to follow bug 321299
Flags: blocking1.8.0.6+
Flags: blocking1.8.0.5-
Flags: blocking1.8.0.5+
If bug 321299 is blocking 1.8.1 then this should be also.
Flags: blocking1.8.1?
Flags: blocking1.8.1? → blocking1.8.1+
Target Milestone: mozilla1.9alpha → mozilla1.8.1beta2
(Assignee)

Comment 40

11 years ago
This is really fixed on the 1.8 branch already.
Keywords: fixed1.8.1
Whiteboard: regression from 321299 → regression from 321299 (fix incorporated into 321299 branch patch)
(Assignee)

Comment 41

11 years ago
I checked a combined patch into the 1.8.0 branch.
Keywords: fixed1.8.0.7
>+            JSObject *newParent = aOldScope;
>+            rv = sciWrapper.GetCallback()->PreCreate(identity, ccx, aOldScope,
>+                                                     &newParent);
...
>+            // Now, reparent the wrapper, since we know that it wants to be
>+            // reparented.
>+
>+            XPCWrappedNative *junk;
>+            rv = XPCWrappedNative::ReparentWrapperIfFound(ccx, oldScope,
>+                                                          newScope, aNewScope,
>+                                                          wrapper->GetIdentityObject(),
>+                                                          &junk);

Shouldn't this have used newParent as the parent instead of aNewScope?
Depends on: 356851
Er... yes.  It should.  Bug 356851 filed.
(Assignee)

Comment 44

11 years ago
(In reply to comment #42)=
> Shouldn't this have used newParent as the parent instead of aNewScope?

It doesn't matter. See the assertion inside the |if(newParent != aOldScope)| condition: the betterScope found from the newParent must be the same as aNewScope.
Why would that matter? It just compares with the scope of newParent, that doesn't mean that newParent == aNewScope.
(Assignee)

Comment 46

11 years ago
Sorry, I misread... Yeah, it should.
Flags: in-testsuite?

Updated

11 years ago
Flags: blocking1.9a1?
Flags: blocking1.7.14?
Flags: blocking-aviary1.0.9?
You need to log in before you can comment on or make changes to this bug.