Closed
Bug 425814
Opened 17 years ago
Closed 17 years ago
"Report Broken Web Site..." Broken with Adblock Plus or No Script
Categories
(Other Applications Graveyard :: Reporter, defect, P2)
Other Applications Graveyard
Reporter
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: longhair, Assigned: smaug)
References
Details
(Keywords: relnote)
Attachments
(6 files, 2 obsolete files)
2.87 KB,
patch
|
Details | Diff | Splinter Review | |
1.52 KB,
patch
|
Gavin
:
review-
|
Details | Diff | Splinter Review |
9.34 KB,
patch
|
Details | Diff | Splinter Review | |
3.64 KB,
patch
|
Details | Diff | Splinter Review | |
6.57 KB,
patch
|
sicking
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
6.82 KB,
patch
|
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032605 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032605 Minefield/3.0b5pre
Clicking help->report broken web site... gives me the popup with no privacy notice in the box, just white space, and when I check the box agreeing to it and click 'finish' it just disappears, no reporting tool displayed.
Reproducible: Always
Steps to Reproduce:
1. Explained in details.
2.
3.
It's hard to report problems if the reporting tools don't work. :)
Comment 1•17 years ago
|
||
works for me, we had today the same report for a localized version in the #testday channel. Can you try with a new profile (http://support.mozilla.com/en-US/kb/Managing+profiles) if you still see the problem ?
Comment 2•17 years ago
|
||
I noticed after seeing this bug that I see the problem as well. I've found that if I have either Adblock Plus or No Script enabled that I see the problem.
Comment 3•17 years ago
|
||
The regression range that I found is right at the 3-21 nightly build. The previous hourly build is ok. But nothing that regression range is even used.
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1206103020&maxdate=1206112319
So this could have been uncovered by the nightly clobber. So the range would be from the 3-20 nightly to the 3-21 nightly.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-20+05%3A00%3A00&maxdate=2008-03-21+04%3A00%3A00&cvsroot=%2Fcvsroot
Bug 424444 had the same regression range as this bug and was caused by something before the regression range.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•17 years ago
|
Flags: blocking-firefox3?
Updated•17 years ago
|
Summary: Minefield Nightly 2008032605 "Report Broken Web Site..." Broken → "Report Broken Web Site..." Broken with Adblock Plus or No Script
Updated•17 years ago
|
Assignee: nobody → robert
Component: General → Reporter
Flags: blocking-firefox3?
OS: Windows XP → All
Product: Firefox → Other Applications
QA Contact: general → xul-client
Hardware: PC → All
Version: unspecified → Trunk
Updated•17 years ago
|
Flags: blocking1.9?
Comment 4•17 years ago
|
||
I missed the error message:
Error: document.getElementById("dontShowPrivacyStatement") is null
Source File: chrome://reporter/content/reportWizard.js
Line: 118
Comment 5•17 years ago
|
||
Yes, I see that as well. Checked with Adblock Plus Watcher - Adblock Plus isn't blocking anything here (actually returning early for all the calls here because they are initiated by chrome). More likely, the presence of a JavaScript content policy changes the initialization of the dialog somehow.
Comment 6•17 years ago
|
||
requesting relnote keyword, since this also affects beta 5
Keywords: relnote
Comment 7•17 years ago
|
||
assigning to JST to determine how serious this is
Assignee: robert → jst
Flags: blocking1.9? → blocking1.9+
Comment 11•17 years ago
|
||
Here's the JS stack when we get the error about getElementById("dontShowPrivacyStatement") returning null:
1 setPrivacyPref() ["chrome://reporter/content/reportWizard.js":118]
2 anonymous(event = [object Event @ 0xa086c80 (native @ 0xa428b50)]) ["chrome://global/content/bindings/wizard.xml":410]
3 _fireEvent(aType = "pageadvanced", aTarget = [object XULElement @ 0x9fcac80 (native @ 0xa25c910)]) ["chrome://global/content/bindings/wizard.xml":411]
4 advance(aPageId = undefined) ["chrome://global/content/bindings/wizard.xml":257]
5 initPrivacyNotice() ["chrome://reporter/content/reportWizard.js":98]
6 anonymous(event = [object Event @ 0xa02c440 (native @ 0xa422940)]) ["chrome://global/content/bindings/wizard.xml":410]
7 _fireEvent(aType = "pageshow", aTarget = [object XULElement @ 0x9fcac80 (native @ 0xa25c910)]) ["chrome://global/content/bindings/wizard.xml":411]
8 set_currentPage(val = [object XULElement @ 0x9fcac80 (native @ 0xa25c910)]) ["chrome://global/content/bindings/wizard.xml":94]
9 advance(aPageId = undefined) ["chrome://global/content/bindings/wizard.xml":284]
10 () ["chrome://global/content/bindings/wizard.xml":199]
And the C++ stack is rougly this:
#0 nsXULDocument::GetElementById (this=0xa24c000, aId=@0xbffcdac4,
aReturn=0xbffcd830)
#1 0x00366a65 in NS_InvokeByIndex_P ()
#2 0x0726f457 in XPCWrappedNative::CallMethod (ccx=@0xbffcda50,
mode=XPCWrappedNative::CALL_METHOD)
[...]
#19 0x001aaa7f in JS_CallFunctionValue (cx=0xa010c80, obj=0x9ecd140,
fval=166517248, argc=0, argv=0x0, rval=0xbffcfbb8)
#20 0x08635746 in nsXBLProtoImplAnonymousMethod::Execute (this=0xa5bd1a0,
aBoundElement=0xa27a6d0)
#21 0x0862a291 in nsXBLPrototypeBinding::BindingAttached (this=0x9f98800,
aBoundElement=0xa27a6d0)
#22 0x08623637 in nsXBLBinding::ExecuteAttachedHandler (this=0xa451480)
#23 0x086e6676 in nsElementSH::PostCreate (this=0x9ace680, wrapper=0x9f80180,
cx=0x9676360, obj=0x9ecd140)
#24 0x07274565 in XPCWrappedNative::GetNewOrUsed (ccx=@0xbffd0058,
Object=0xa27a6d0, Scope=0x9b50200, Interface=0x96d3f00, isGlobal=0,
resultWrapper=0xbffcffbc)
[...]
#27 0x07221f40 in nsXPConnect::WrapNative (this=0x96edbc0,
aJSContext=0x9676360, aScope=0x996a1a0, aCOMObj=0xa27a6d0,
aIID=@0x897f890, _retval=0xbffd0120)
#28 0x086df602 in nsDOMClassInfo::WrapNative (cx=0x9676360, scope=0x996a1a0,
native=0xa27a6d0, aIID=@0x897f890, vp=0xbffd0190, aHolder=0xbffd018c)
#29 0x086e05de in nsNodeSH::PreCreate (this=0x9ace680, nativeObj=0xa25c910,
cx=0x9676360, globalObj=0x996a1a0, parentObj=0xbffd0294)
#30 0x07273d20 in XPCWrappedNative::GetNewOrUsed (ccx=@0xbffd03d8,
Object=0xa25c910, Scope=0x999e380, Interface=0x96d3f00, isGlobal=0,
resultWrapper=0xbffd033c)
[...]
#38 0x086df602 in nsDOMClassInfo::WrapNative (cx=0x9676360, scope=0x996a1a0,
native=0xa25c9a0, aIID=@0x897f890, vp=0xbffd0890, aHolder=0xbffd088c)
#39 0x086e05de in nsNodeSH::PreCreate (this=0x9ace680, nativeObj=0xa25c9d0,
cx=0x9676360, globalObj=0x996a1a0, parentObj=0xbffd0994)
#40 0x07273d20 in XPCWrappedNative::GetNewOrUsed (ccx=@0xbffd0bf0,
Object=0xa25c9ec, Scope=0x999e380, Interface=0x96d3f00, isGlobal=0,
resultWrapper=0xbffd0a3c)
#41 0x072449ff in XPCConvert::NativeInterface2JSObject (ccx=@0xbffd0bf0,
dest=0xbffd0b10, src=0xa25c9ec, iid=0xbffd0d40, scope=0x99ce6e0,
allowNativeWrapper=1, isGlobal=0, pErr=0x0)
#42 0x07248282 in XPCConvert::NativeData2JS (ccx=@0xbffd0bf0, d=0xbffd0cec,
s=0xbffd0ee8, type=@0xbffd0d71, iid=0xbffd0d40, scope=0x99ce6e0, pErr=0x0)
#43 0x072672f4 in nsXPCWrappedJSClass::CallMethod (this=0x99ff910,
wrapper=0x9c5a5c0, methodIndex=3, info=0x99ee1a8, nativeParams=0xbffd0ed0)
#44 0x0725ec71 in nsXPCWrappedJS::CallMethod (this=0x9c5a5c0, methodIndex=3,
info=0x99ee1a8, params=0xbffd0ed0)
#45 0x003678f6 in PrepareAndDispatch (methodIndex=3, self=0x9c4a630,
args=0xbffd0f94)
#46 0x083f1db4 in nsContentPolicy::CheckPolicy (this=0x9999f70,
policyMethod=<error reading variable>, contentType=6,
contentLocation=0xa263ab0, requestingLocation=0xa1ed0e0,
requestingContext=0xa25c9ec, mimeType=@0x3aa410, extra=0x0,
decision=0xbffd13fe)
#47 0x083f10c2 in nsContentPolicy::ShouldLoad (this=0x9999f70, contentType=6,
contentLocation=0xa263ab0, requestingLocation=0x0,
requestingContext=0xa25c9ec, mimeType=@0x3aa410, extra=0x0,
decision=0xbffd13fe)
#48 0x077ed45d in NS_CheckContentLoadPolicy (contentType=6,
contentLocation=0xa263ab0, originPrincipal=0x0, context=0xa25c9ec,
mimeType=@0x3aa410, extra=0x0, decision=0xbffd13fe, policyService=0x0,
aSecMan=0x0)
#49 0x077ccb17 in nsDocShell::InternalLoad (this=0x96413e0, aURI=0xa263ab0,
aReferrer=0x0, aOwner=0x0, aFlags=1, aWindowTarget=0x961f2b8,
aTypeHint=0x0, aPostData=0x0, aHeadersData=0x0, aLoadType=1, aSHEntry=0x0,
aFirstParty=0, aDocShell=0x0, aRequest=0x0)
[...]
#54 0x084471a8 in nsFrameLoader::LoadFrame (this=0xa41e4c0)
#55 0x087a2551 in nsXULElement::LoadSrc (this=0xa25c9d0)
#56 0x087a4eeb in nsXULElement::BindToTree (this=0xa25c9d0,
aDocument=0xa24c000, aParent=0xa25c9a0, aBindingParent=0x0,
aCompileEventHandlers=1)
#57 0x08457fa5 in nsGenericElement::doInsertChildAt (aKid=0xa25c9d0, aIndex=0,
aNotify=0, aParent=0xa25c9a0, aDocument=0xa24c000, aChildArray=@0xa25c9b8)
#58 0x08458210 in nsGenericElement::InsertChildAt (this=0xa25c9a0,
aKid=0xa25c9d0, aIndex=0, aNotify=0)
#59 0x087a2f00 in nsXULElement::InsertChildAt (this=0xa25c9a0, aKid=0xa25c9d0,
aIndex=0, aNotify=0)
#60 0x0812c5eb in nsINode::AppendChildTo (this=0xa25c9a0, aKid=0xa25c9d0,
aNotify=0)
#61 0x0865fd1f in nsXULDocument::ResumeWalk (this=0xa24c000)
#62 0x08660ce2 in nsXULDocument::OnStreamComplete ()
So it looks like we're executing an XBL constructor sooner than we should because of the content policy check that goes out into JS and thus wraps a DOM node... Cc:ing Jonas as he's been all over the XBL code recently.
Comment 12•17 years ago
|
||
This was caused by bug 395609. Smaug, any thoughts here? Your change made us load XUL frames earlier (in BindToTree() rather than once we're in layout. I'm not sure we really can do anything about that, othar than document that change and fix this code up.
Thoughts?
Comment 13•17 years ago
|
||
Smaug, see my previous comment.
I really think this needs to be fixed in the frontend code. The code is relying on a very bogus assumption, that the xbl ctor won't run until long after the node has been inserted in the tree and the xbl binding has been attached.
This work should be done in onload or some such, or move the node around so that the xbl-bound node is after the requested node.
Comment 16•17 years ago
|
||
Robert, you wrote this code didn't you? Any early thoughts on how this coulde be fixed in the report broken website wizard?
Comment 17•17 years ago
|
||
jst and robert and I discussed this on IRC earlier. An easy workaround would be to have the reporter code use an onload listener to call initPrivacyNotice() for the first panel, rather than relying on the "onpageshow" pseudo-event that's fired from the wizard constructor.
That wouldn't fix other wizards that might also have this bug, though. I don't see a clean way to fix this in a generic way, since the dialog code can't tell whether or not the document is loaded yet (so it can't reliably defer calling event handlers until onload).
Assignee | ||
Comment 18•17 years ago
|
||
(In reply to comment #15)
> I really think this needs to be fixed in the frontend code.
I agree. Will look at the chrome code ASAP.
Comment 19•17 years ago
|
||
(In reply to comment #17)
> That wouldn't fix other wizards that might also have this bug, though. I don't
> see a clean way to fix this in a generic way, since the dialog code can't tell
> whether or not the document is loaded yet (so it can't reliably defer calling
> event handlers until onload).
You would need a fix for bug 347174 for that, I would think.
Comment 20•17 years ago
|
||
By the way: Since I can't report a broken website the normal way, I think that you should know that Pandora Radio (pandora.com) doesn't work properly. The tuner loads and the songs appear, but the songs don't play.
Comment 21•17 years ago
|
||
(In reply to comment #20)
> By the way: Since I can't report a broken website the normal way, I think that
> you should know that Pandora Radio (pandora.com) doesn't work properly.
Please file a separate bug on that, let's keep this bug about the problem described here and use new bugs for unrelated issues.
Assignee | ||
Comment 22•17 years ago
|
||
This is not nice, but fixes this bug.
There is something strange happening here. If I have ABP installed, I end up
with different DOM in the reporter dialog. It has only the first wizardpage
element. Does content policy (implemented in JavaScript) disturb XUL loading
somehow? Sounds like a bug which fixing bug 395609 somehow revealed.
If I don't any better way, I'll try delaying XUL frame loading until the
main document is fully loaded or something.
Assignee | ||
Comment 23•17 years ago
|
||
Actually, the DOM is right, but DOMi doesn't report it correctly or something.
My guess is that XBL gets bound "too early" to documentElement if
JS content policy does something.
Comment 24•17 years ago
|
||
This is an alternative to Smaug's fix. This makes initPrivacyNotice() a no-op if called before the window is done loading, and makes the onload handler call initPrivacyNotice(). Seems to work here...
Robert/Gavin/Smaug, what do you think of either of these approaches?
Assignee | ||
Comment 25•17 years ago
|
||
Jst, Jonas, as far as I see this bug has actually always been there.
Bug 395609 just made it visible in this case.
If XBL is bound to some element while content sink (without notifying) still
creates the DOM, XBL may not be up-to-date.
So, the idea in this patch is to update XBL if the parent of inserted/append
/removed node is somehow in XBL, even if aNotify is PR_FALSE.
The change to wizard.xml is needed to delay some initialization.
DOMContentLoaded is fired after initial reflow.
Passes mochitest, chrome and browser tests.
Initial testing shows that the special handling for XBL is called very rarely,
basically in FF UI only when opening 'ReportBroken' dialog.
If this is too scary (though shouldn't be that scary, and IMO is the right
thing to do), Jst's "delay" patch might be good enough.
And now it is really time to sleep :)
Comment on attachment 314230 [details] [diff] [review]
update XBL even when not notifying
This one scares me a little. Even if it is the RightThing we know that our XBL usage is very shaky and even fixing true bugs often end up breaking things relying on those bugs.
Also, won't these notifications reach the bindingmanager eventually? The sink should notify on this content at some point, even though it might be SomeTimeLater? So if we notify manually now we'd cause the notification to happen twice.
Finally, is there any risk that notifying on the bindingmanager when aNotify is false could end up causing script to run?
Assignee | ||
Comment 27•17 years ago
|
||
(In reply to comment #26)
> Also, won't these notifications reach the bindingmanager eventually?
Ah, äh. Not in XUL, which I was debugging, but in HTML.
> Finally, is there any risk that notifying on the bindingmanager when aNotify is
> false could end up causing script to run?
I tried to go through those methods and they just update the data structures of
XBL bindings..
I'm inclined to say that we should hold that patch for post 1.9 and instead do a pure frontend workaround for now.
Assignee | ||
Comment 29•17 years ago
|
||
Well, here is anyway a patch which doesn't have the problem with
multiple notifications. NODE_MAY_BE_IN_BINDING_MNGR is used to optimize out
the common cases when notifying bindingmanager wouldn't do anything.
Attachment #314230 -
Attachment is obsolete: true
Comment 30•17 years ago
|
||
Comment on attachment 314225 [details] [diff] [review]
Delay initPrivacyNotice()
Robert/Gavin, I think we should do this for now, and take Smaug's patch later. What's your thoughts?
Attachment #314225 -
Flags: superreview?(gavin.sharp)
Attachment #314225 -
Flags: review?(robert)
Comment 31•17 years ago
|
||
Comment on attachment 314225 [details] [diff] [review]
Delay initPrivacyNotice()
You can't go back to the privacy notice pane, so you can just move the call to initPrivacyNotice from the pane's onpageshow to the wizard's onload.
This will fix this specific instance of the bug, but it won't address other users of this widget that might rely on the document being "ready" when the constructor is called. It's hard to know how many potential users like that exist, but it would be nice to not break them... seems like smaug's patch would be better in this regard (although the dialog.xml change looks like it would break dialogs added after the document has loaded - perhaps not an important enough use case that we need to worry about it). I can't really evaluate the riskiness of it, though, so I'll defer to your judgement there.
Attachment #314225 -
Flags: superreview?(gavin.sharp)
Attachment #314225 -
Flags: review?(robert)
Attachment #314225 -
Flags: review-
Assignee | ||
Comment 32•17 years ago
|
||
(In reply to comment #31)
> seems like smaug's patch would
> be better in this regard (although the dialog.xml change looks like it would
> break dialogs added after the document has loaded - perhaps not an important
> enough use case that we need to worry about it).
What dialog.xml change?
<wizard> is expected (at least the code expects si) to be the root element, so
no new <wizard> elements after load.
Comment 33•17 years ago
|
||
Er, sorry, I meant wizard.xml. You're right, that part of your patch is very unlikely to be a problem.
Comment 34•17 years ago
|
||
Attachment #314470 -
Flags: superreview?(gavin.sharp)
Attachment #314470 -
Flags: review?(gavin.sharp)
Updated•17 years ago
|
Attachment #314470 -
Flags: superreview?(gavin.sharp)
Attachment #314470 -
Flags: review?(gavin.sharp)
Attachment #314470 -
Flags: review+
Updated•17 years ago
|
Whiteboard: [needs landing
Comment 35•17 years ago
|
||
Sigh. Turns out my patch didn't fix this problem at all :( It did in my tree, but what I didn't realize when I was testing was that I had locally backed out Smaugs patch that introduced this problem in the first place :(
With the patch the reporter wizard page closes right away when you open it and you have adblock installed :(
Updated•17 years ago
|
Attachment #314470 -
Attachment is obsolete: true
Comment 36•17 years ago
|
||
Gavin says he's got a plan for making the wizard code not advance a wizard before the page is done loading, which would fix this in better and more general way. Reassigning.
Assignee: jst → gavin.sharp
Assignee | ||
Comment 38•17 years ago
|
||
(In reply to comment #36)
> Gavin says he's got a plan for making the wizard code not advance a wizard
> before the page is done loading,
But the problem is that the XBL code isn't updated properly if the binding
is attached to the <wizard> element too early. Use DOMi to see what the
non-anonymous code looks inside the binding.
Maybe re-binding XBL to <wizard> when DOMContentLoaded fires could help here.
That would be an ugly hack though.
Comment 39•17 years ago
|
||
smaug's right - this patch fixes the exception and makes the initial privacy pane work (by deferring the wizard events until DOMContentLoaded), but it's not sufficient. The wizard is still broken, because the document is missing wizardpage elements even after it has fully loaded.
Comment 40•17 years ago
|
||
Reassigning back to smaug, since it looks like we'll need to take his patch (or something like it).
Assignee: gavin.sharp → Olli.Pettay
Assignee | ||
Comment 41•17 years ago
|
||
Comment on attachment 314332 [details] [diff] [review]
update XBL even when not notifying, v2
So, is this too scary?
Attachment #314332 -
Flags: review?(jonas)
Comment 42•17 years ago
|
||
I'd be pretty afraid of touching that XBL stuff, myself... It's very fragile, and not well tested. It's buggy in various ways, but we don't want to change those ways if we can avoid it, this late in the game.
It does seem like this would be a problem for anything in XUL that loads from content, though. Or for any XUL that uses an inline script. And I'm sure the lack of notifications in XUL also causes bugs in content lists, and so forth.
So really, we just need to fix XUL to notify properly... That's clearly not 1.9-scope, though.
Comment 43•17 years ago
|
||
To fix this bug, I could live with special-casing xul:frame to not start loading immediately if StartLayout() hasn't been called yet, and starting that load when StartLayout() does happen.
Assignee | ||
Comment 44•17 years ago
|
||
(In reply to comment #42)
> So really, we just need to fix XUL to notify properly... That's clearly not
> 1.9-scope, though.
The bug isn't about XUL not notifying properly but XBL not getting updated when
there have been some updates to DOM.
(In reply to comment #43)
> To fix this bug, I could live with special-casing xul:frame to not start
> loading immediately if StartLayout() hasn't been called yet, and starting that
> load when StartLayout() does happen.
That is possible, yes. Ugly, but possible.
That seems less scary. Isn't that what happened before smaugs change?
Past 1.9 I think we should do what comment 42 says.
Comment 46•17 years ago
|
||
Yes, I realize what this bug is about. I'm just saying that changing the notification setup all over to deal with the XUL brokenness is pretty worrisome at this point...
Assignee | ||
Comment 47•17 years ago
|
||
I don't understand what does this have to do with XUL? The same bug might,
I think, happen on HTML too.
But special casing XUL documents to wait until StartLayout() might be good
enough here.
Assignee | ||
Comment 48•17 years ago
|
||
Comment on attachment 314332 [details] [diff] [review]
update XBL even when not notifying, v2
Maybe this is too scary at this point.
Attachment #314332 -
Flags: review?(jonas)
Assignee | ||
Comment 49•17 years ago
|
||
Passes mochitest, browser and chrome without those new assertions or warnings.
Attachment #315081 -
Flags: review?(jonas)
Comment 50•17 years ago
|
||
Apparently, there is another place where the same bug manifests - plugin installer. Alexander Sack sent me a report about this issue that he found on Linux, but it is reproducible on Windows as well. You need to have some JavaScript content policy installed - Adblock Plus or NoScript will do (minimal content policy has the same effect). Steps to reproduce:
1. Make sure Quicktime plugin isn't installed and go to http://www.gottamovefaster.com/quicktime/
2. Click "Click here to download plugin" message
3. Wait for the wizard to offer you Quicktime and click Next.
The wizard simply disappears. Next wizard page would contain an iframe where the license terms of the plugin should load into.
Smaug, can you check whether your patch fixes this issue as well?
Comment 51•17 years ago
|
||
Comment 52•17 years ago
|
||
attachment 314332 [details] [diff] [review] fixes the plugin installer wizard for me. I'd like to use that for ubuntu as it breaks an imporant use-case for users of popular extensions (adblock plug, noscript).
smaug, any concrete risks in mind (comment 48)?
Comment 53•17 years ago
|
||
How about we don't start forking stuff for now, eh?
I wonder why the "defer loading" patch doesn't fix the issue...
Updated•17 years ago
|
Whiteboard: [needs landing
Comment 54•17 years ago
|
||
Is PFS not working correctly (bug 424421) just another manifestation of this bug?
Comment 55•17 years ago
|
||
Reed: I bet, since I have ABP 0.7.5.4 due to ads everywhere. No NoScript.
Definitely needs to go to the ABP team and the devs so that they can work together on a fix.
Comment 56•17 years ago
|
||
(In reply to comment #53)
> How about we don't start forking stuff for now, eh?
>
I have a release milestone hanging over me ;) ... definitly don't want to fork.
> I wonder why the "defer loading" patch doesn't fix the issue...
>
i did a clean respin and have to admit that i stand corrected: my claim in comment 51 is wrong; attachment 315081 [details] [diff] [review] fixes the pfs for me too! Sorry for the noise ;).
Assignee | ||
Comment 57•17 years ago
|
||
(In reply to comment #56)
> i did a clean respin and have to admit that i stand corrected: my claim in
> comment 51 is wrong; attachment 315081 [details] [diff] [review] fixes the pfs for me too! Sorry for the
> noise ;).
So let's try attachment 315081 [details] [diff] [review] then. Jonas, (or bz) reviews?
This implementation makes me a little nervous. Do all displayed XUL documents always go through DoneWalking? Including content ones? It's also not super future proof since we might some day allow things like let XSLT create XUL documents, or let you create documents through the DOM and then insert them into a docshell.
Comment 59•17 years ago
|
||
> Do all displayed XUL documents always go through DoneWalking?
Yes.
> It's also not super future proof
It's a temporary "safe for 1.9 at this point" measure until we fix the XUL notification breakage...
Attachment #315081 -
Flags: review?(jonas) → review+
Assignee | ||
Updated•17 years ago
|
Attachment #315081 -
Flags: superreview?(bzbarsky)
Comment 61•17 years ago
|
||
Comment on attachment 315081 [details] [diff] [review]
delay frame loading
>Index: content/base/src/nsDocument.h
>+ PRBool mDelayFrameLoaderInitialization;
Put this up with our earlier PRBool bitfield (right after mHasWarnedAboutBoxObjects)?
With that looks ok.
Attachment #315081 -
Flags: superreview?(bzbarsky) → superreview+
Assignee | ||
Comment 62•17 years ago
|
||
Attachment #316283 -
Flags: approval1.9?
Comment 63•17 years ago
|
||
Is there a way to put tests around this? The "not super future proof" scares me a little to a lot.
Assignee | ||
Comment 64•17 years ago
|
||
I don't know any reasonable way to test this automatically :(
I'd say the "not super future proof" is about post 1.9.
Yes, that things that might break this are adding new features. Something that won't happen in 1.9.0.x.
Comment 66•17 years ago
|
||
Comment on attachment 316283 [details] [diff] [review]
delay frame loading + PRPackedBool
a1.9=beltzner
Attachment #316283 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 67•17 years ago
|
||
It's looking like this may have broken Firebug's loading of a chrome HTML page in a xul:browser (the load is triggered from the load event of another xul:browser)? Bug 411814 has more details, would very much like anyone's help with it.
Depends on: 411814
See Also: → https://launchpad.net/bugs/215672
Updated•6 years ago
|
Product: Other Applications → Other Applications Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•