Closed
Bug 620615
Opened 14 years ago
Closed 14 years ago
New tab-modal alerts can make Firefox unable to quit.
Categories
(Toolkit :: General, defect)
Toolkit
General
Tracking
()
VERIFIED
FIXED
mozilla2.0b11
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: BijuMailList, Assigned: khuey)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: [hardblocker])
Attachments
(4 files)
437 bytes,
text/html
|
Details | |
54.91 KB,
text/plain
|
Details | |
3.32 KB,
patch
|
Dolske
:
review+
|
Details | Diff | Splinter Review |
833 bytes,
patch
|
Dolske
:
review+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows NT 6.0; rv:2.0b9pre) Gecko/20101219 Firefox/4.0b9pre This issue is similar to bug 613800. But work around for this issue is not resolving bug 613800. Hence creating a new bug... New tab-modal alerts can make Firefox unable to quit. But this is not issue if we do an additional step, see step 6 in StR. Steps:- Phase I 1. Open 2 tabs 2. in one tab navigate to attachment alert_issues.html 3. Click "Start Test" 4. wait 5 seconds 5. when alerts popup dismiss first 2 of them 6. now navigate to "about:blank" on same tab 7. Close the same tab by clicking "x" on the Tab 8. Exit Firefox 9. Restart Firefox (Firefox restarts without an issue) Phase II 10. Again open 2 tabs 11. in one tab navigate to attachment alert_issues.html 12. Click "Start Test" 13. wait 5 seconds 14. when alerts popup dismiss first 2 of them 15. Close the same tab by clicking "x" on the Tab 16. Exit Firefox 17. Restart Firefox again Result:- on Phase II, Firefox is unable to restart, user get message Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system. So cant we do a programmatic action similar to step 6 when user close a tab to avoid similar issues?
Comment 1•14 years ago
|
||
This sounds like something we need to investigate - it seems like we're probably not exiting the dialog event loops for some reason.
blocking2.0: --- → betaN+
Comment 2•14 years ago
|
||
Simpler STR can work for me (on Windows 7 32-bit Gecko/20101221). 1. open the attached testcase, with another tab open (any page) 2. click "Start Tests", and click OK for first two alerts 3. close testcase tab (by clicking X button) 4. close Firefox * firefox process stays resident in memory 5. attempt to re-launch Firefox * not possible
Assignee | ||
Comment 3•14 years ago
|
||
I can't reproduce this on tip.
(In reply to comment #3) > I can't reproduce this on tip. I am able to always reproduce this in Win XP and Vista. On Ubuntu I see firefox-bin in "futex_wait_queue_me" waiting channel after following the phase II STR
OS: Windows Vista → All
Hardware: x86 → All
Assignee | ||
Comment 5•14 years ago
|
||
Can you post the full stack?
Comment 6•14 years ago
|
||
I can repro. I'm not sure what to break on to get a useful stack though, if you can point me to a useful Shutdown function to break on, I'd appreciate it.
Assignee | ||
Comment 7•14 years ago
|
||
Just attach and dump the stack once we're hung?
Comment 8•14 years ago
|
||
(In reply to comment #7) > Just attach and dump the stack once we're hung? It's a useless windows stack. 0:033> kp ChildEBP RetAddr 08cefc2c 7776c9a0 ntdll!DbgBreakPoint 08cefc5c 76e7d0e9 ntdll!DbgUiRemoteBreakin+0x3c 08cefc68 777219bb kernel32!BaseThreadInitThunk+0xe 08cefca8 7772198e ntdll!__RtlUserThreadStart+0x23 08cefcc0 00000000 ntdll!_RtlUserThreadStart+0x1b
Comment 9•14 years ago
|
||
Didn't get the other threads, here's a full stack trace.
Assignee | ||
Comment 10•14 years ago
|
||
Thanks! So we're in a nested event loop with JS on the stack. Sounds like comment 3 is correct.
Assignee | ||
Comment 11•14 years ago
|
||
er, comment 1 of course
Assignee | ||
Comment 12•14 years ago
|
||
I can reproduce now. Investigating.
Assignee | ||
Comment 13•14 years ago
|
||
When closing the tab, I get
************************************************************
* Call to xpconnect wrapped JSObject produced this error: *
[Exception... "'JavaScript component does not have a method named: "handleEvent"' when calling metho
d: [nsIDOMEventListener::handleEvent]" nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION
_NAMED)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no]
************************************************************
with the following stack
> xul.dll!nsXPCWrappedJSClass::CheckForException(XPCCallContext & ccx, const char * aPropertyName, const char * anInterfaceName, int aForceReport) Line 1174 C++
xul.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper, unsigned short methodIndex, const XPTMethodDescriptor * info, nsXPTCMiniVariant * nativeParams) Line 1735 + 0x21 bytes C++
xul.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex, const XPTMethodDescriptor * info, nsXPTCMiniVariant * params) Line 588 + 0x13 bytes C++
xul.dll!PrepareAndDispatch(nsXPTCStubBase * self, unsigned int methodIndex, unsigned int * args, unsigned int * stackBytesToPop) Line 114 + 0x1a bytes C++
xul.dll!SharedStub() Line 142 C++
xul.dll!nsEventListenerManager::HandleEventSubType(nsListenerStruct * aListenerStruct, nsIDOMEventListener * aListener, nsIDOMEvent * aDOMEvent, nsPIDOMEventTarget * aCurrentTarget, unsigned int aPhaseFlags, nsCxPusher * aPusher) Line 1114 + 0x9 bytes C++
0045a958()
xul.dll!nsXPConnect::Push(JSContext * cx) Line 2511 + 0xb bytes C++
xul.dll!nsCxPusher::DoPush(JSContext * cx) Line 2995 + 0x9 bytes C++
xul.dll!nsCxPusher::Push(JSContext * cx, int aRequiresScriptContext) Line 2978 + 0xb bytes C++
xul.dll!nsCxPusher::Push(nsPIDOMEventTarget * aCurrentTarget) Line 2925 + 0xa bytes C++
xul.dll!nsEventListenerManager::HandleEventInternal(nsPresContext * aPresContext, nsEvent * aEvent, nsIDOMEvent * * aDOMEvent, nsPIDOMEventTarget * aCurrentTarget, unsigned int aFlags, nsEventStatus * aEventStatus, nsCxPusher * aPusher) Line 1211 + 0x1a bytes C++
xul.dll!nsEventListenerManager::HandleEvent(nsPresContext * aPresContext, nsEvent * aEvent, nsIDOMEvent * * aDOMEvent, nsPIDOMEventTarget * aCurrentTarget, unsigned int aFlags, nsEventStatus * aEventStatus, nsCxPusher * aPusher) Line 146 + 0x18 bytes C++
xul.dll!nsEventTargetChainItem::HandleEvent(nsEventChainPostVisitor & aVisitor, unsigned int aFlags, int aMayHaveNewListenerManagers, nsCxPusher * aPusher) Line 213 C++
xul.dll!nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor & aVisitor, unsigned int aFlags, nsDispatchingCallback * aCallback, int aMayHaveNewListenerManagers, nsCxPusher * aPusher) Line 343 C++
xul.dll!nsEventDispatcher::Dispatch(nsISupports * aTarget, nsPresContext * aPresContext, nsEvent * aEvent, nsIDOMEvent * aDOMEvent, nsEventStatus * aEventStatus, nsDispatchingCallback * aCallback, nsCOMArray<nsPIDOMEventTarget> * aTargets) Line 628 + 0x16 bytes C++
xul.dll!nsEventDispatcher::DispatchDOMEvent(nsISupports * aTarget, nsEvent * aEvent, nsIDOMEvent * aDOMEvent, nsPresContext * aPresContext, nsEventStatus * aEventStatus) Line 691 + 0x14 bytes C++
xul.dll!nsDocument::DispatchPageTransition(nsPIDOMEventTarget * aDispatchTarget, const nsAString_internal & aType, int aPersisted) Line 7324 + 0xe bytes C++
xul.dll!nsDocument::OnPageHide(int aPersisted, nsIDOMEventTarget * aDispatchStartTarget) Line 7435 + 0x2a bytes C++
xul.dll!DocumentViewerImpl::PageHide(int aIsUnload) Line 1269 C++
xul.dll!nsDocShell::FirePageHideNotification(int aIsUnload) Line 1521 C++
xul.dll!nsDocShell::Destroy() Line 4488 C++
xul.dll!nsFrameLoader::Finalize() Line 424 C++
xul.dll!nsDocument::MaybeInitializeFinalizeFrameLoaders() Line 5471 + 0x17 bytes C++
xul.dll!nsDocument::EndUpdate(unsigned int aUpdateType) Line 3978 + 0x7 bytes C++
xul.dll!nsXULDocument::EndUpdate(unsigned int aUpdateType) Line 3320 C++
xul.dll!mozAutoDocUpdate::~mozAutoDocUpdate() Line 66 + 0x12 bytes C++
xul.dll!nsINode::doRemoveChildAt(unsigned int aIndex, int aNotify, nsIContent * aKid, nsAttrAndChildArray & aChildArray, int aMutationEvent) Line 3684 + 0x2a bytes C++
xul.dll!nsGenericElement::RemoveChildAt(unsigned int aIndex, int aNotify, int aMutationEvent) Line 3624 + 0x14 bytes C++
xul.dll!nsXULElement::RemoveChildAt(unsigned int aIndex, int aNotify, int aMutationEvent) Line 1010 C++
xul.dll!nsINode::RemoveChild(nsINode * aOldChild) Line 485 + 0xc bytes C++
xul.dll!nsIDOMNode_RemoveChild(JSContext * cx, unsigned int argc, jsval_layout * vp) Line 6094 C++
mozjs.dll!js::CallJSNative(JSContext * cx, int (JSContext *, unsigned int, js::Value *)* native, unsigned int argc, js::Value * vp) Line 684 + 0x7 bytes C++
mozjs.dll!js::Interpret(JSContext * cx, JSStackFrame * entryFrame, unsigned int inlineCallCount, JSInterpMode interpMode) Line 4744 + 0x14 bytes C++
mozjs.dll!js::RunScript(JSContext * cx, JSScript * script, JSStackFrame * fp) Line 657 + 0xb bytes C++
mozjs.dll!js::Invoke(JSContext * cx, const js::CallArgs & argsRef, unsigned int flags) Line 737 + 0x8 bytes C++
mozjs.dll!js::ExternalInvoke(JSContext * cx, const js::Value & thisv, const js::Value & fval, unsigned int argc, js::Value * argv, js::Value * rval) Line 858 + 0xd bytes C++
mozjs.dll!JS_CallFunctionValue(JSContext * cx, JSObject * obj, jsval_layout fval, unsigned int argc, jsval_layout * argv, jsval_layout * rval) Line 5029 C++
xul.dll!nsJSContext::CallEventHandler(nsISupports * aTarget, void * aScope, void * aHandler, nsIArray * aargv, nsIVariant * * arv) Line 2177 + 0x1c bytes C++
xul.dll!nsJSEventListener::HandleEvent(nsIDOMEvent * aEvent) Line 228 + 0x34 bytes C++
xul.dll!nsXBLPrototypeHandler::ExecuteHandler(nsPIDOMEventTarget * aTarget, nsIDOMEvent * aEvent) Line 333 C++
xul.dll!nsXBLEventHandler::HandleEvent(nsIDOMEvent * aEvent) Line 90 C++
xul.dll!nsEventListenerManager::HandleEventSubType(nsListenerStruct * aListenerStruct, nsIDOMEventListener * aListener, nsIDOMEvent * aDOMEvent, nsPIDOMEventTarget * aCurrentTarget, unsigned int aPhaseFlags, nsCxPusher * aPusher) Line 1114 + 0x9 bytes C++
xul.dll!nsEventListenerManager::HandleEventInternal(nsPresContext * aPresContext, nsEvent * aEvent, nsIDOMEvent * * aDOMEvent, nsPIDOMEventTarget * aCurrentTarget, unsigned int aFlags, nsEventStatus * aEventStatus, nsCxPusher * aPusher) Line 1211 + 0x1a bytes C++
xul.dll!nsEventListenerManager::HandleEvent(nsPresContext * aPresContext, nsEvent * aEvent, nsIDOMEvent * * aDOMEvent, nsPIDOMEventTarget * aCurrentTarget, unsigned int aFlags, nsEventStatus * aEventStatus, nsCxPusher * aPusher) Line 146 + 0x18 bytes C++
xul.dll!nsEventTargetChainItem::HandleEvent(nsEventChainPostVisitor & aVisitor, unsigned int aFlags, int aMayHaveNewListenerManagers, nsCxPusher * aPusher) Line 213 C++
xul.dll!nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor & aVisitor, unsigned int aFlags, nsDispatchingCallback * aCallback, int aMayHaveNewListenerManagers, nsCxPusher * aPusher) Line 366 C++
xul.dll!nsEventDispatcher::Dispatch(nsISupports * aTarget, nsPresContext * aPresContext, nsEvent * aEvent, nsIDOMEvent * aDOMEvent, nsEventStatus * aEventStatus, nsDispatchingCallback * aCallback, nsCOMArray<nsPIDOMEventTarget> * aTargets) Line 628 + 0x16 bytes C++
xul.dll!nsTransitionManager::WillRefresh(mozilla::TimeStamp aTime) Line 1010 + 0x12 bytes C++
xul.dll!nsRefreshDriver::Notify(nsITimer * __formal) Line 256 C++
xul.dll!nsTimerImpl::Fire() Line 441 C++
xul.dll!nsTimerEvent::Run() Line 519 C++
xul.dll!nsThread::ProcessNextEvent(int mayWait, int * result) Line 626 + 0xe bytes C++
xul.dll!NS_InvokeByIndex_P(nsISupports * that, unsigned int methodIndex, unsigned int paramCount, nsXPTCVariant * params) Line 103 C++
xul.dll!CallMethodHelper::Invoke() Line 3064 + 0x11 bytes C++
xul.dll!CallMethodHelper::Call() Line 2328 C++
xul.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx, XPCWrappedNative::CallMode mode) Line 2290 + 0x10 bytes C++
xul.dll!XPC_WN_CallMethod(JSContext * cx, unsigned int argc, jsval_layout * vp) Line 1588 + 0xa bytes C++
051fff68()
mozjs.dll!js::ExecuteTrace(JSContext * cx, nanojit::Fragment * f, js::TracerState & state) Line 6420 C++
mozjs.dll!js::ExecuteTree(JSContext * cx, js::TreeFragment * f, unsigned int & inlineCallCount, js::VMSideExit * * innermostNestedGuardp, js::VMSideExit * * lrp) Line 6520 + 0xf bytes C++
mozjs.dll!js::RecordLoopEdge(JSContext * cx, unsigned int & inlineCallCount) Line 7069 + 0x28 bytes C++
mozjs.dll!js::Interpret(JSContext * cx, JSStackFrame * entryFrame, unsigned int inlineCallCount, JSInterpMode interpMode) Line 2907 + 0x142 bytes C++
mozjs.dll!js::RunScript(JSContext * cx, JSScript * script, JSStackFrame * fp) Line 657 + 0xb bytes C++
mozjs.dll!js::Invoke(JSContext * cx, const js::CallArgs & argsRef, unsigned int flags) Line 737 + 0x8 bytes C++
mozjs.dll!js::mjit::stubs::SlowCall(js::VMFrame & f, unsigned int argc) Line 198 + 0x24 bytes C++
mozjs.dll!SlowCallFromIC(js::VMFrame & f, js::mjit::ic::CallICInfo * ic) Line 426 C++
mozjs.dll!js::mjit::EnterMethodJIT(JSContext * cx, JSStackFrame * fp, void * code, js::Value * stackLimit) Line 745 + 0x24 bytes C++
mozjs.dll!js::mjit::JaegerShot(JSContext * cx) Line 787 + 0x1b bytes C++
mozjs.dll!js::RunScript(JSContext * cx, JSScript * script, JSStackFrame * fp) Line 654 + 0x6 bytes C++
mozjs.dll!js::Invoke(JSContext * cx, const js::CallArgs & argsRef, unsigned int flags) Line 737 + 0x8 bytes C++
mozjs.dll!js::ExternalInvoke(JSContext * cx, const js::Value & thisv, const js::Value & fval, unsigned int argc, js::Value * argv, js::Value * rval) Line 858 + 0xd bytes C++
mozjs.dll!JS_CallFunctionValue(JSContext * cx, JSObject * obj, jsval_layout fval, unsigned int argc, jsval_layout * argv, jsval_layout * rval) Line 5029 C++
xul.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper, unsigned short methodIndex, const XPTMethodDescriptor * info, nsXPTCMiniVariant * nativeParams) Line 1699 C++
xul.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex, const XPTMethodDescriptor * info, nsXPTCMiniVariant * params) Line 588 + 0x13 bytes C++
xul.dll!PrepareAndDispatch(nsXPTCStubBase * self, unsigned int methodIndex, unsigned int * args, unsigned int * stackBytesToPop) Line 114 + 0x1a bytes C++
xul.dll!SharedStub() Line 142 C++
xul.dll!nsGlobalWindow::Alert(const nsAString_internal & aString) Line 4638 + 0x1a bytes C++
006a0048()
xul.dll!nsGlobalWindow::Alert(const nsAString_internal & aString) Line 4580 + 0xa bytes C++
xul.dll!NS_InvokeByIndex_P(nsISupports * that, unsigned int methodIndex, unsigned int paramCount, nsXPTCVariant * params) Line 103 C++
xul.dll!CallMethodHelper::Invoke() Line 3064 + 0x11 bytes C++
xul.dll!CallMethodHelper::Call() Line 2328 C++
xul.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx, XPCWrappedNative::CallMode mode) Line 2290 + 0x10 bytes C++
xul.dll!XPC_WN_CallMethod(JSContext * cx, unsigned int argc, jsval_layout * vp) Line 1588 + 0xa bytes C++
02681041()
xul.dll!nsJSContext::CallEventHandler(nsISupports * aTarget, void * aScope, void * aHandler, nsIArray * aargv, nsIVariant * * arv) Line 2177 + 0x1c bytes C++
We're firing onPageHide, which is one of the things nsPrompter.js listens for to close the tab-modal prompt and exit the nested event loop. That event gets lost so we never shut down the prompts.
Assignee | ||
Comment 14•14 years ago
|
||
Somehow the <tabmodalprompt> is getting destroyed before pagehide fires. If I add a call to shutdown the prompt in the destructor this bug goes away.
Updated•14 years ago
|
Product: Core → Toolkit
QA Contact: general → general
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → khuey
Status: NEW → ASSIGNED
Updated•14 years ago
|
Whiteboard: [hard blocker]
Updated•14 years ago
|
Whiteboard: [hard blocker] → [hardblocker]
Assignee | ||
Comment 15•14 years ago
|
||
Assignee | ||
Comment 16•14 years ago
|
||
Comment on attachment 505276 [details] [diff] [review] Make double-extra-sure that we shutdown the prompt. I can't reproduce this on tip anymore .... That said, this is the patch I have in my queue for this. It's purely defensive programming, so it wouldn't hurt to take this. I don't think we can test this.
Attachment #505276 -
Flags: review?(dolske)
Updated•14 years ago
|
Whiteboard: [hardblocker] → [hardblocker][has patch][needs review dolske]
Assignee | ||
Comment 17•14 years ago
|
||
Biju, can you still reproduce this on tip?
Whiteboard: [hardblocker][has patch][needs review dolske] → [hardblocker][has patch][needs review dolske][wfm?]
Comment 18•14 years ago
|
||
Comment on attachment 505276 [details] [diff] [review] Make double-extra-sure that we shutdown the prompt. Urk. Part of me doesn't want to do this, lest we wallpaper over something that shouldn't be failing anyway (and since XBL destructors apparently don't always fire, we get a hard-to-reproduce hang). OTOH, we're close to ship, and better to only hang when 2 rare failures happen instead of when 1 rare failure happens.
Attachment #505276 -
Flags: review?(dolske) → review+
Reporter | ||
Comment 19•14 years ago
|
||
I can always reproduce this on WinXP and Vista following steps in "Phase II" Mozilla/5.0 (Windows NT 6.0; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre
Assignee | ||
Comment 20•14 years ago
|
||
OK, I'll check this in next time I push then.
Whiteboard: [hardblocker][has patch][needs review dolske][wfm?] → [hardblocker][has patch]
Reporter | ||
Comment 21•14 years ago
|
||
Kyle, can you please check whether Bug 613800 also get resolved with this patch
Updated•14 years ago
|
Keywords: checkin-needed
Whiteboard: [hardblocker][has patch] → [hardblocker][ready to land]
Comment 22•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/42847b167826
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [hardblocker][ready to land] → [hardblocker]
Target Milestone: --- → mozilla2.0b11
Reporter | ||
Comment 23•14 years ago
|
||
Mozilla/5.0 (Windows NT 6.0; rv:2.0b11pre) Gecko/20110126 Firefox/4.0b11pre Tested on WinXP and Vista it still FAILS on Comment 0 phase II What should we reopen this bug or create a new one ? (In reply to comment #21) STR at Bug 613800 Comment 5 - still fails STR at Bug 613800 Comment 0 - this was already passing Vista before landing attachment 505276 [details] [diff] [review]
Comment 24•14 years ago
|
||
I reproduced this on Windows XP. It looks like the call that sets the flag to make us exit the event loop was missing. If it may be of interest, it seems to me that the prompt that is shut down abnormally in the XBL destructor is not the last prompt that is displayed, but a new prompt that is triggered by the fact that when the tab is closed we exit modal state and thus we run pending timeouts, causing a new "alert" call to be made immediately while we are closing the tab.
Attachment #508052 -
Flags: review?(dolske)
Updated•14 years ago
|
Whiteboard: [hardblocker] → [hardblocker][has patch]
Comment 25•14 years ago
|
||
Comment on attachment 508052 [details] [diff] [review] Addition Sigh, I suck for missing this.
Attachment #508052 -
Flags: review?(dolske) → review+
Updated•14 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 26•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/10c381463850
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 27•14 years ago
|
||
Backed out due to test failures http://hg.mozilla.org/mozilla-central/rev/10c381463850
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 28•14 years ago
|
||
I think I see what might be happening... During a normal prompt shutdown [ie, a call to shutdownPrompt()], we execute onCloseCallback() and then set isLive=false. The problem is that onCloseCallback removes the prompt from the DOM (indeed, that's the whole reason we added the callback). If the destructor is run then, isLive is still true, and so it calls abortPrompt(). Bam. Indeed, the tinderbox failure is: [SimpleTest/SimpleTest.js, window.onerror] An error occurred - uncaught exception: [Exception... "prompt aborted by user" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: resource://gre/components/nsPrompter.js :: openTabPrompt :: line 468" data: no] at :0 Should be able to fix this by setting isLive to false before invoking the callback.
Comment 29•14 years ago
|
||
Removing the misleading checkin-needed.
Keywords: checkin-needed
Whiteboard: [hardblocker][has patch] → [hardblocker][needs new patch]
Comment 30•14 years ago
|
||
Sorry, I should have said from the start that this was just a drive-by suggestion. I guess you I assumed I ran the various test suites because I attached a patch, but I didn't intend to take the bug, as I'm working on other things at the moment. I hope this hasn't caused too much trouble.
Assignee | ||
Comment 31•14 years ago
|
||
It's not a problem Paolo. Thanks for finding the issue in the original patch. I'll finish this up later this week.
Comment 32•14 years ago
|
||
I made (and tested ;) the small change I suggested in comment 28 and relanded... Pushed http://hg.mozilla.org/mozilla-central/rev/76b361ae1c3a
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Whiteboard: [hardblocker][needs new patch] → [hardblocker]
Reporter | ||
Comment 33•14 years ago
|
||
Comment 0 phase II Mozilla/5.0 (Windows NT 6.0; rv:2.0b12pre) Gecko/20110202 Firefox/4.0b12pre - PASS Mozilla/5.0 (Windows NT 6.0; rv:2.0b11pre) Gecko/20110201 Firefox/4.0b11pre - FAIL
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•