Closed Bug 474406 Opened 15 years ago Closed 15 years ago

[FIX]CPU usage peaking at 100% on Lufthansa website

Categories

(Core :: XBL, defect)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: der.ozean, Assigned: bzbarsky)

References

()

Details

(4 keywords)

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.6pre) Gecko/2009011500 Camino/2.0b2pre (like Firefox/3.0.6pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.6pre) Gecko/2009011500 Camino/2.0b2pre (like Firefox/3.0.6pre)

CPU starts to rise to around 100% as soon as I modify one of the date fields on the Lufthansa booking search date fields. It stays at this high level and makes quitting Camino impossible without resorting to a force-quit.

OS X 10.5.6, no Camino add-ons or haxies installed. Ad-block is on, as are Flash-block and pop-up suppression.

Reproducible: Always

Steps to Reproduce:
This is the unpromlematic part of the sequence:

1. click into the From: field and enter a city
2. press tab key to move to the Depart on: field
3. select a date with a mouse click
4. click into the To: field and enter another city
5. press tab key to move to the Return on: field
6. select another date with a mouse click

Now comes the problematic part:

7. use your mouse to click (or the tab key) to get into either the Depart: or Return: field to select a different date

this will send the processor usage flying!

Actual Results:  
CPU usage is nearing 100% (i.e. on of the two cores of my C2D MacBook Pro 2.33Ghz). Camino remains useable but it becomes really slow. In addition, it is not possible to quit Camino without issuing a force-quit. Memory use seems to stay at a stable level.

Expected Results:  
no particular increase in CPU usage and no problems in quitting Camino

I have a process sample, taken right after the CPU accelerating click:
http://pastebin.com/f4b176589

There has also been some discussion of this bug in the Camino forum (you can find more samples there and also a console hang-report):
http://forums.mozillazine.org/viewtopic.php?f=12&t=1044265
Ah, forgot this: on the forum, phiw13 stated: “I tried next with Minefield latest nightly, then Fx 3.05 release build, and the nightly of what will be Fx 3.0.6, but none of them had a problem.” So this really seems to be a Camino-specific bug…
(In reply to comment #1)
> Ah, forgot this: on the forum, phiw13 stated: “I tried next with Minefield
> latest nightly, then Fx 3.05 release build, and the nightly of what will be Fx
> 3.0.6, but none of them had a problem.” So this really seems to be a
> Camino-specific bug…

Yes, I tested Minefield latest, the official FX 3.05 build and the Gran Paradiso nightly (3.06pre) and none of them had problems.

Confirming the issue meanwhile.
Status: UNCONFIRMED → NEW
Ever confirmed: true
the content of this attachment is the same as what is provided in the pastebin link in the bug description
Does this happen in 1.6.6, too, or just 2.0*?
It does not happen in 1.6.6.
(I tried it on another 10.5.6 machine (MacBook C2D), also with flash- and adblock turned on)
I don't think flash has anything to do with this. The problem happens when Camino attempts to reload the calendar (loaded from an iframe).

Regression window:
works
2007120400 (2.0a1pre)
fails
2007120500 (2.0a1pre)

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=2007-12-04+00%3A00%3A00&maxdate=2007-12-05+01%3A00%3A00&cvsroot=%2Fcvsroot

[between 2008010800 (2.0a1pre) and 2008011500 (2.0a1pre) there was some change in behaviour; after 20080115 it works 'better' in that one needs to click a second time in the first date field for the hang to happen. Before that, moving away from the first date field was enough to send the cpu into the 100%+ zone, and hang.]
There are a handful of layout checkins in that range:

Bug 406568
Bug 402567
Bug 375304
Bug 392809
Bug 406485
Bug 404209
Bug 406852
Bug 383195

There are also three event checkins in there:

Bug 404870
Bug 376077 (Cocoa widget)
Bug 401743 (which also has to do with XBL bindings, and nsBindingManager shows up in the sample stack)
Keywords: regression
philippe, do you have any idea how to reduce this into a testcase?
Keywords: hang
The layout bugs seem unlikely, as does the Cocoa widget change (if it was doing some fun swizzling, I'd be all over that, though). I think bug 404870 and bug 401743 are the most likely.

roc and bz: Do either of you see any reason why your patch(es) would cause an issue like this? Is there more debugging we can do to help figure out the issue here?
Possible, but unlikely in the XBL case.

This is not reproducible in Firefox, right?

Can someone who can reproduce with a Camino build (not a camino nightly) get a shark profile?  The sample linked from comment 0 is for a build with no debug symbols looks, like, so of limited utility...
Here's a plain-old sample from right after clicking back into the departure date field (because I think it might be small enough to attach to Bugzilla and be viewable; the with-Flash plain-old sample was not).

I'm the farthest thing in the world from a Shark adept, but I've uploaded two profiles (Flashblock on, to match Lars's experience and generally get the excess Flash noise out of the sample; and Flashblock off) begun just before clicking back into the departure date field and ended shortly after clicking back into that field.  Both of the samples that I took earlier are also uploaded.  http://www.ardisson.org/smokey/moz/bug474406/
Hmm.  The flashblocked profile shows us processing lots of events and spending about 30% of our time in kernel code...  I guess that matches the samples, sort of.  It's just not very informative, since all the time is spent outside Gecko (in Cocoa and the kernel).  :(

At this point I'd be willing to believe pretty much anything that sends us into a loop of some sort....  Is someone willing to just sit down and try compiling builds across that day and hunting down the exact checkin responsible?
Works: 

make -f client.mk checkout MOZ_CO_DATE="04 December 2007 08:56 PST" ; cvs up -r1.5 content/html/content/src/nsHTMLSelectElement.h ; make -f client.mk build

Fails: 

make -f client.mk MOZ_CO_DATE="04 December 2007 09:35 PST"

That does look like it points to bug 401743 :(
Blocks: 401743
I assume that trying to back that patch out locally with patch -R will lead to the same result.

Here's a question.  I assume you're ending up in DoProcessAttachedQueue with mProcessingAttachedStack true, right?  And that it happens over and over again?  If so, can you get me the stack at that point?
(In reply to comment #14)
> I assume that trying to back that patch out locally with patch -R will lead to
> the same result.

Yes, backing that out of a current tree gets us back to no CPU spike/hang.

> Here's a question.  I assume you're ending up in DoProcessAttachedQueue with
> mProcessingAttachedStack true, right?  And that it happens over and over again?
>  If so, can you get me the stack at that point?

Stuart's going to try to look into this tonight.
Sorry, I'm having to wrestle with my tree a bit so I couldn't look at it tonight after all. I'll give it another shot tomorrow.
(In reply to comment #14)
> I assume you're ending up in DoProcessAttachedQueue with
> mProcessingAttachedStack true, right?  And that it happens over and over again?

Yep.

>  If so, can you get me the stack at that point?

#0  nsBindingManager::DoProcessAttachedQueue (this=0x1a9a32d0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/xbl/src/nsBindingManager.cpp:943
#1  0x139c90e9 in nsRunnableMethod<nsBindingManager>::Run (this=0x1f34db10) at nsThreadUtils.h:261
#2  0x0033f95c in nsThread::ProcessNextEvent (this=0x9baad0, mayWait=0, result=0xbfffe454) at /Volumes/Chambord/Camino/trees/trunk/mozilla/xpcom/threads/nsThread.cpp:510
#3  0x002c9ece in NS_ProcessPendingEvents_P (thread=0x9baad0, timeout=20) at nsThreadUtils.cpp:180
#4  0x159389bf in nsBaseAppShell::NativeEventCallback (this=0x15ca0c40) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:121
#5  0x158f3e58 in nsAppShell::ProcessGeckoEvents (aInfo=0x15ca0c40) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsAppShell.mm:302
#6  0x93b035f5 in CFRunLoopRunSpecific ()
#7  0x93b03cd8 in CFRunLoopRunInMode ()
#8  0x9255d2c0 in RunCurrentEventLoopInMode ()
#9  0x9255d012 in ReceiveNextEventCommon ()
#10 0x9255cf4d in BlockUntilNextEventMatchingListInMode ()
#11 0x90569d7d in _DPSNextEvent ()
#12 0x90569630 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#13 0x9056266b in -[NSApplication run] ()
...
That's the whole stack?  Nothing else?

If so, then that boolean just has the wrong value, no?
Just NSApplicationMain and main. I'm not sure what the boolean is for, not being familiar with this code, but I can tell you it's PR_TRUE because just before things hit the fan nsBindingManager::DropDocumentReference is called on the object that gets into the loop of death, which is the last time mProcessingAttachedStack is set for it:

#0  nsBindingManager::DropDocumentReference (this=0x1cfc02a0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/xbl/src/nsBindingManager.cpp:1472
#1  0x139c14f4 in nsNodeInfoManager::DropDocumentReference (this=0x1b78d8c0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsNodeInfoManager.cpp:210
#2  0x139855a9 in nsDocument::~nsDocument (this=0x1060400) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsDocument.cpp:877
#3  0x13ac8d91 in nsHTMLDocument::~nsHTMLDocument (this=0x1060400) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:380
#4  0x139c361e in nsNodeUtils::LastRelease (aNode=0x1060400) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsNodeUtils.cpp:245
#5  0x139734a4 in nsDocument::Release (this=0x1060400) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsDocument.cpp:950
#6  0x13ac6810 in nsHTMLDocument::Release (this=0x1060400) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:419
#7  0x1386f8a2 in nsCOMPtr<nsIDocument>::assign_assuming_AddRef (this=0x1cfbce30, newPtr=0x0) at nsCOMPtr.h:568
#8  0x136df546 in nsCOMPtr<nsIDocument>::assign_with_AddRef (this=0x1cfbce30, rawPtr=0x0) at nsCOMPtr.h:1267
#9  0x136df70a in nsCOMPtr<nsIDocument>::operator= (this=0x1cfbce30, rhs=0x0) at nsCOMPtr.h:713
#10 0x13c0a980 in nsGlobalWindow::SetDocShell (this=0x1cfbccc0, aDocShell=0x0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/dom/src/base/nsGlobalWindow.cpp:2040
#11 0x14fa354d in nsDocShell::Destroy (this=0x1cfbd170) at /Volumes/Chambord/Camino/trees/trunk/mozilla/docshell/base/nsDocShell.cpp:3728
#12 0x13998ab2 in nsFrameLoader::Finalize (this=0x1b78f4d0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsFrameLoader.cpp:279
#13 0x13981e10 in nsDocument::InitializeFinalizeFrameLoaders (this=0x1042200) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsDocument.cpp:3921
#14 0x13981f35 in nsDocument::EndUpdate (this=0x1042200, aUpdateType=1) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsDocument.cpp:2760
#15 0x13ad364d in nsHTMLDocument::EndUpdate (this=0x1042200, aUpdateType=1) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:3752
#16 0x1376b555 in mozAutoDocUpdate::~mozAutoDocUpdate (this=0xbfffcea4) at ../../content/base/src/mozAutoDocUpdate.h:66
#17 0x139aae7f in nsGenericElement::doRemoveChildAt (aIndex=30, aNotify=1, aKid=0x1b7a8cc0, aParent=0x1cf4d940, aDocument=0x1042200, aChildArray=@0x1cf4d958) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsGenericElement.cpp:2851
#18 0x139aaf7f in nsGenericElement::RemoveChildAt (this=0x1cf4d940, aIndex=30, aNotify=1) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsGenericElement.cpp:2776
#19 0x139a4f5f in nsGenericElement::doRemoveChild (aOldChild=0x1b7a8ce8, aParent=0x1cf4d940, aDocument=0x1042200, aReturn=0xbfffd1a4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsGenericElement.cpp:3438
#20 0x139a4fc8 in nsGenericElement::RemoveChild (this=0x1cf4d940, aOldChild=0x1b7a8ce8, aReturn=0xbfffd1a4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/base/src/nsGenericElement.cpp:3004
#21 0x13a58027 in nsHTMLBodyElement::RemoveChild (this=0x1cf4d940, oldChild=0x1b7a8ce8, _retval=0xbfffd1a4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/content/src/nsHTMLBodyElement.cpp:95
#22 0x0035a3b3 in NS_InvokeByIndex_P (that=0x1cf4d95c, methodIndex=17, paramCount=2, params=0xbfffd194) at /Volumes/Chambord/Camino/trees/trunk/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179
#23 0x00df47e3 in XPCWrappedNative::CallMethod (ccx=@0xbfffd3ec, mode=XPCWrappedNative::CALL_METHOD) at /Volumes/Chambord/Camino/trees/trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393
#24 0x00dfece5 in XPC_WN_CallMethod (cx=0x18e7b480, obj=0x170cc660, argc=1, argv=0x1363730, vp=0xbfffd52c) at /Volumes/Chambord/Camino/trees/trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1473
#25 0x132392a4 in js_Invoke (cx=0x18e7b480, argc=1, vp=0x1363728, flags=2) at jsinterp.c:1304
#26 0x1322c2cf in js_Interpret (cx=0x18e7b480) at /Volumes/Chambord/Camino/trees/trunk/mozilla/js/src/jsinterp.c:4864
#27 0x13239319 in js_Invoke (cx=0x18e7b480, argc=1, vp=0x1363624, flags=0) at jsinterp.c:1320
#28 0x132395d9 in js_InternalInvoke (cx=0x18e7b480, obj=0x170cdcc0, fval=386719360, flags=0, argc=1, argv=0x1363620, rval=0xbfffde4c) at jsinterp.c:1376
#29 0x131d99c6 in JS_CallFunctionValue (cx=0x18e7b480, obj=0x170cdcc0, fval=386719360, argc=1, argv=0x1363620, rval=0xbfffde4c) at /Volumes/Chambord/Camino/trees/trunk/mozilla/js/src/jsapi.c:5054
#30 0x13be34b4 in nsJSContext::CallEventHandler (this=0x18e7b3d0, aTarget=0x1b71ea40, aScope=0x170cfca0, aHandler=0x170cde80, aargv=0x1b74da90, arv=0xbfffdfdc) at /Volumes/Chambord/Camino/trees/trunk/mozilla/dom/src/base/nsJSEnvironment.cpp:1962
#31 0x13c5454b in nsJSEventListener::HandleEvent (this=0x1b735240, aEvent=0x1b7ec440) at /Volumes/Chambord/Camino/trees/trunk/mozilla/dom/src/events/nsJSEventListener.cpp:248
#32 0x13a0872f in nsEventListenerManager::HandleEventSubType (this=0x1b72e9d0, aListenerStruct=0x1b72fe70, aListener=0x1b735240, aDOMEvent=0x1b7ec440, aCurrentTarget=0x1b71ea40, aPhaseFlags=6) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventListenerManager.cpp:1080
#33 0x13a0a3f7 in nsEventListenerManager::HandleEvent (this=0x1b72e9d0, aPresContext=0x17e1f030, aEvent=0xbfffe50c, aDOMEvent=0xbfffe3d0, aCurrentTarget=0x1b71ea40, aFlags=6, aEventStatus=0xbfffe3d4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventListenerManager.cpp:1185
#34 0x13a3815a in nsEventTargetChainItem::HandleEvent (this=0x13e6820, aVisitor=@0xbfffe3c8, aFlags=6) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventDispatcher.cpp:210
#35 0x13a38337 in nsEventTargetChainItem::HandleEventTargetChain (this=0x13e6ae0, aVisitor=@0xbfffe3c8, aFlags=6, aCallback=0x0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventDispatcher.cpp:268
#36 0x13a38bb4 in nsEventDispatcher::Dispatch (aTarget=0x1b71ea40, aPresContext=0x17e1f030, aEvent=0xbfffe50c, aDOMEvent=0x0, aEventStatus=0xbfffe590, aCallback=0x0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventDispatcher.cpp:483
#37 0x13a18d0d in nsEventStateManager::SendFocusBlur (this=0x9dc1b0, aPresContext=0x17e1f030, aContent=0x1b71d9e0, aEnsureWindowHasFocus=1) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventStateManager.cpp:4546
#38 0x13a19fe0 in nsEventStateManager::SetContentState (this=0x9dc1b0, aContent=0x1b71d9e0, aState=2) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventStateManager.cpp:4255
#39 0x13a48a55 in nsGenericHTMLFormElement::SetFocusAndScrollIntoView (this=0x1b71d9e0, aPresContext=0x17e1f030) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:2875
#40 0x13a7d5ae in nsHTMLInputElement::SetFocus (this=0x1b71d9e0, aPresContext=0x17e1f030) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/html/content/src/nsHTMLInputElement.cpp:1300
#41 0x13a13913 in nsEventStateManager::ChangeFocusWith (this=0x9dc1b0, aFocusContent=0x1b71d9e0, aFocusedWith=eEventFocusedByMouse) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventStateManager.cpp:3396
#42 0x13a1816f in nsEventStateManager::PostHandleEvent (this=0x9dc1b0, aPresContext=0x17e1f030, aEvent=0xbfffede4, aTargetFrame=0x138b400, aStatus=0xbfffeb18, aView=0x17edf040) at /Volumes/Chambord/Camino/trees/trunk/mozilla/content/events/src/nsEventStateManager.cpp:2405
#43 0x1370d42a in PresShell::HandleEventInternal (this=0x1222000, aEvent=0xbfffede4, aView=0x17edf040, aStatus=0xbfffeb18) at /Volumes/Chambord/Camino/trees/trunk/mozilla/layout/base/nsPresShell.cpp:5954
#44 0x1370d6a1 in PresShell::HandlePositionedEvent (this=0x1222000, aView=0x17edf040, aTargetFrame=0x138b400, aEvent=0xbfffede4, aEventStatus=0xbfffeb18) at /Volumes/Chambord/Camino/trees/trunk/mozilla/layout/base/nsPresShell.cpp:5821
#45 0x1370f6bb in PresShell::HandleEvent (this=0x1222000, aView=0x17edf040, aEvent=0xbfffede4, aEventStatus=0xbfffeb18) at /Volumes/Chambord/Camino/trees/trunk/mozilla/layout/base/nsPresShell.cpp:5681
#46 0x13bcfd64 in nsViewManager::HandleEvent (this=0x17edefe0, aView=0x17edf040, aPoint=@0xbfffebfc, aEvent=0xbfffede4, aCaptured=0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/view/src/nsViewManager.cpp:1382
#47 0x13bd0cc3 in nsViewManager::DispatchEvent (this=0x17edefe0, aEvent=0xbfffede4, aStatus=0xbfffec88) at /Volumes/Chambord/Camino/trees/trunk/mozilla/view/src/nsViewManager.cpp:1337
#48 0x13bc6c31 in HandleEvent (aEvent=0xbfffede4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/view/src/nsView.cpp:168
#49 0x18b6cf31 in nsChildView::DispatchEvent (this=0x1cfa1940, event=0xbfffede4, aStatus=@0xbfffed5c) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsChildView.mm:1718
#50 0x18b5ffd6 in nsChildView::DispatchWindowEvent (this=0x1cfa1940, event=@0xbfffede4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsChildView.mm:1731
#51 0x18b6cae6 in nsChildView::DispatchMouseEvent (this=0x1cfa1940, aEvent=@0xbfffede4) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsChildView.mm:1743
#52 0x18b6d7f2 in -[ChildView mouseDown:] (self=0x1cfa19e0, _cmd=0x961e2918, theEvent=0x1b7a16a0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsChildView.mm:3032
#53 0x906381a3 in -[NSWindow sendEvent:] ()
#54 0x18b5e15c in -[NSWindow(MethodSwizzling) nsCocoaWindow_NSWindow_sendEvent:] (self=0x17ecc2b0, _cmd=0x961b34b8, anEvent=0x1b7a16a0) at /Volumes/Chambord/Camino/trees/trunk/mozilla/widget/src/cocoa/nsCocoaWindow.mm:2153
#55 0x90604d49 in -[NSApplication sendEvent:] ()
#56 0x9056269f in -[NSApplication run] ()
#57 0x9052f8a4 in NSApplicationMain ()
Oh, well, there we go.  That stack is exactly what I needed.  Thank you!

I have no idea why this doesn't bite other Gecko-based browsers.  This code is clearly wrong.
Status: NEW → ASSIGNED
Component: General → XBL
Flags: wanted1.9.1?
Product: Camino → Core
QA Contact: general → xbl
Summary: CPU usage peaking at 100% on Lufthansa website → [FIX]CPU usage peaking at 100% on Lufthansa website
Attached patch Proposed fixSplinter Review
Stuart, can you check whether this fixes the issue for you?

Also, do you plan to ship off of 1.9.0 or 1.9.1?
Assignee: nobody → bzbarsky
Attachment #360310 - Flags: superreview?(jonas)
Attachment #360310 - Flags: review?(jonas)
I'll have to answer those questions in reverse order:

> Also, do you plan to ship off of 1.9.0 or 1.9.1?

We have to ship from 1.9.0, unfortunately. After the move to Hg some people decided that because Camino was no longer in the same repository, we no longer mattered, and completely removed several legacy components that we still rely on and had been led to believe for some time would continue to be available through all of 1.9. We don't have the manpower to rewrite several sections of Camino a year or two ahead of schedule, so we can't use 1.9.1.

> Stuart, can you check whether this fixes the issue for you?

It looks like 1.9.0 will need a different patch; it applies, but the build fails:
error: ‘class nsDerivedSafe<nsRunnableMethod<nsBindingManager> >’ has no member named ‘Revoke’
(Sorry if it's just a simple function substitution; I'm out of time for the morning so I can't dig beyond that right now.)
> and completely removed several legacy components that we still rely
> on and had been led to believe for some time would continue to be available

Removed from hg (as in not imported into mozilla-central), or removed altogether?  Please feel free to mail me with details, ok?

I'll post a 1.9.0 patch.
Attached patch 1.9.0 fixSplinter Review
Attachment #360310 - Flags: superreview?(jonas)
Attachment #360310 - Flags: superreview+
Attachment #360310 - Flags: review?(jonas)
Attachment #360310 - Flags: review+
Comment on attachment 360324 [details] [diff] [review]
1.9.0 fix

Works like a charm :)
(In reply to comment #24)
> Created an attachment (id=360324) [details]
> 1.9.0 fix

Works perfectly. :-)
Attachment #360310 - Flags: approval1.9.1?
Pushed http://hg.mozilla.org/mozilla-central/rev/ed041ee82ec6
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attachment #360324 - Flags: approval1.9.0.8?
Attachment #360324 - Flags: approval1.9.0.7?
Comment on attachment 360324 [details] [diff] [review]
1.9.0 fix

last-minute approcal for 1.9.0.7, a=dveditz for release-drivers -- if you're around still to land it. Otherwise it'll be 1.9.0.8
Attachment #360324 - Flags: approval1.9.0.8?
Attachment #360324 - Flags: approval1.9.0.7?
Attachment #360324 - Flags: approval1.9.0.7+
Checked into CVS.
Keywords: fixed1.9.0.7
I figure we should nominate this for blocking 1.9.1, since it's fixed everywhere else...
Flags: blocking1.9.1?
Verified FIXED in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.7pre) Gecko/2009020500 Camino/2.0b2pre (like Firefox/3.0.7pre)

Thanks, Boris, for the amazing turn-around on this!
Flags: blocking1.9.1? → blocking1.9.1+
Attachment #360310 - Flags: approval1.9.1?
verified FIXED on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090403 Shiretoko/3.5b4pre ID:20090403030624

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090331 Minefield/3.6a1pre ID:20090331030637
Status: RESOLVED → VERIFIED
Removing verification markers for everything except 1.9.0.

Aakash: This issue was only visible in Camino (though bz isn't sure why, see comment 20) and can only be verified with Camino, which doesn't have builds using either 1.9.1 or trunk, only 1.8.1 and 1.9.0.
Status: VERIFIED → RESOLVED
Closed: 15 years ago15 years ago
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: