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

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).

Are you using http or https?

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

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

Agreed, but it helps to describe the actual problem better :)

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.

(In reply to comment #8) > No idea. Ask in that bug? I can't , it's a security_group-only bug

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.

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.... :(

I'm curious why this only affects https Gmail, and I'm curious what a reduced testcase would look like.

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.

strange enough, Gmail works with a cairo build and http, but not with a non-cairo build and http

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

*** Bug 334475 has been marked as a duplicate of this bug. ***

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.

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.

(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.

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

Comment on attachment 218364 [details] [diff] [review] Partial fix Actually, avoiding the locking isn't as feasable as I'd hoped.

*** 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

Fix checked into trunk.

Great! Very welcome patch.

> Fix checked into trunk. I believe this broke the trunk.(In reply to comment #28)

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

(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.

Verified FIXED using 04-27-16 build of SeaMonkey trunk on Windows XP.

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

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

Comment on attachment 218364 [details] [diff] [review] Partial fix Jonas says we'll get a combined branch patch for all the related regressions.

Moving to 1.8.0.6 to follow bug 321299

If bug 321299 is blocking 1.8.1 then this should be also.

This is really fixed on the 1.8 branch already.

I checked a combined patch into the 1.8.0 branch.

>+ 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?

Er... yes. It should. Bug 356851 filed.

(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.

Sorry, I misread... Yeah, it should.