Closed Bug 1606499 Opened 4 years ago Closed 4 years ago

Intermittent Assertion failure: aTerminated || mDocument->GetReadyStateEnum() == Document::READYSTATE_LOADING (Bad readyState), at src/dom/base/nsContentSink.cpp:1376

Categories

(Core :: DOM: Core & HTML, defect, P2)

defect

Tracking

()

RESOLVED FIXED
82 Branch
Tracking Status
firefox-esr68 --- wontfix
firefox-esr78 --- wontfix
firefox73 --- wontfix
firefox80 --- wontfix
firefox81 --- wontfix
firefox82 --- fixed

People

(Reporter: tsmith, Assigned: hsivonen)

References

(Blocks 1 open bug, Regression)

Details

(4 keywords, Whiteboard: [stockwell unknown])

Attachments

(2 files, 1 obsolete file)

Attached file testcase.html

Reduced with m-c:
BuildID=20191231094349
SourceStamp=66a1c07a8f48c5129aa3867813bacb6e7ef22d8c

I'm not sure if this is just a dupe of bug 1423202 or not. Either way this has a simple reliable test case.

Assertion failure: aTerminated || mDocument->GetReadyStateEnum() == Document::READYSTATE_LOADING (Bad readyState), at src/dom/base/nsContentSink.cpp:1376

#0 nsContentSink::DidBuildModelImpl(bool) src/dom/base/nsContentSink.cpp:1394:25
#1 nsHtml5TreeOpExecutor::DidBuildModel(bool) src/parser/html/nsHtml5TreeOpExecutor.cpp:170:3
#2 nsHtml5TreeOpExecutor::FlushDocumentWrite() src/parser/html/nsHtml5TreeOpExecutor.cpp:635:5
#3 nsHtml5Parser::ParseUntilBlocked() src/parser/html/nsHtml5Parser.cpp:577:22
#4 nsHtml5Parser::Parse(nsTSubstring<char16_t> const&, void*, bool) src/parser/html/nsHtml5Parser.cpp:213:14
#5 mozilla::dom::Document::Close(mozilla::ErrorResult&) src/dom/base/Document.cpp:8943:14
#6 mozilla::dom::Document_Binding::close(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) src/obj-firefox/dom/bindings/DocumentBinding.cpp:3069:24
#7 bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) src/dom/bindings/BindingUtils.cpp:3151:13
#8 CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) src/js/src/vm/Interpreter.cpp:452:13
#9 js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) src/js/src/vm/Interpreter.cpp:544:12
#10 InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason) src/js/src/vm/Interpreter.cpp:608:10
#11 Interpret(JSContext*, js::RunState&) src/js/src/vm/Interpreter.cpp:3037:16
#12 js::RunScript(JSContext*, js::RunState&) src/js/src/vm/Interpreter.cpp:424:10
#13 js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) src/js/src/vm/Interpreter.cpp:580:13
#14 InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason) src/js/src/vm/Interpreter.cpp:608:10
#15 js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) src/js/src/vm/Interpreter.cpp:625:8
#16 JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) src/js/src/jsapi.cpp:2753:10
#17 mozilla::dom::Function::Call(JSContext*, JS::Handle<JS::Value>, nsTArray<JS::Value> const&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) src/obj-firefox/dom/bindings/FunctionBinding.cpp:41:8
#18 void mozilla::dom::Function::Call<nsCOMPtr<nsIGlobalObject> >(nsCOMPtr<nsIGlobalObject> const&, nsTArray<JS::Value> const&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JS::Realm*) src/obj-firefox/dist/include/mozilla/dom/FunctionBinding.h:73:12
#19 mozilla::dom::CallbackTimeoutHandler::Call(char const*) src/dom/base/TimeoutHandler.cpp:167:29
#20 nsGlobalWindowInner::RunTimeoutHandler(mozilla::dom::Timeout*, nsIScriptContext*) src/dom/base/nsGlobalWindowInner.cpp:5866:38
#21 mozilla::dom::TimeoutManager::RunTimeout(mozilla::TimeStamp const&, mozilla::TimeStamp const&, bool) src/dom/base/TimeoutManager.cpp:891:44
#22 mozilla::dom::TimeoutExecutor::MaybeExecute() src/dom/base/TimeoutExecutor.cpp:179:11
#23 mozilla::dom::TimeoutExecutor::Run() src/dom/base/TimeoutExecutor.cpp:234:5
#24 mozilla::ThrottledEventQueue::Inner::ExecuteRunnable() src/xpcom/threads/ThrottledEventQueue.cpp:252:22
#25 mozilla::ThrottledEventQueue::Inner::Executor::Run() src/xpcom/threads/ThrottledEventQueue.cpp:80:15
#26 mozilla::SchedulerGroup::Runnable::Run() src/xpcom/threads/SchedulerGroup.cpp:282:20
#27 nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1241:14
#28 NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:486:10
#29 mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:87:21
#30 MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:315:10
#31 MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:290:3
#32 nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:137:27
#33 XRE_RunAppShell() src/toolkit/xre/nsEmbedFunctions.cpp:946:20
#34 mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:237:9
#35 MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:315:10
#36 MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:290:3
#37 XRE_InitChildProcess(int, char**, XREChildData const*) src/toolkit/xre/nsEmbedFunctions.cpp:781:34
#38 content_process_main(mozilla::Bootstrap*, int, char**) src/browser/app/../../ipc/contentproc/plugin-container.cpp:56:28
#39 main src/browser/app/nsBrowserApp.cpp:303:18
Flags: in-testsuite?

A Pernosco session is available here: https://pernos.co/debug/l4K5PT7xY6Dyw01aFBkd8w/index.html

(In reply to Tyson Smith [:tsmith] (PTO Jan 6 - 15) from comment #1)

A Pernosco session is available here: https://pernos.co/debug/l4K5PT7xY6Dyw01aFBkd8w/index.html

Thanks! Perhaps Alphan can take look and confirm if it's a dupe of bug 1423202, when he's back.

Flags: needinfo?(alchen)

It is not that easy to say they are definitely the same.
But I will say that the root cause may be the same.
The two testcases have similar behavior.

  1. Did some document operation.
  2. Do reload() continueously.

Since this testcase is simpler and there is pernosco session here,
I will investigate the symptom based on this bug when I have time.

Assignee: nobody → alchen
Flags: needinfo?(alchen)
Priority: -- → P2
Summary: Assertion failure: aTerminated || mDocument->GetReadyStateEnum() == Document::READYSTATE_LOADING (Bad readyState), at src/dom/base/nsContentSink.cpp:1376 → Intermittent Assertion failure: aTerminated || mDocument->GetReadyStateEnum() == Document::READYSTATE_LOADING (Bad readyState), at src/dom/base/nsContentSink.cpp:1376

In the past week there were 24 failures on:
-macosx1014-64 debug
-linux1804-64 debug

Recent log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=306203506&repo=autoland&lineNumber=1242

Could you take a look?

Flags: needinfo?(alchen)
Whiteboard: [stockwell needswork:owner]

Currently, I am occupied by other urgent tasks and won't have immediate action right now.
Keep an eye on this failure first.

Flags: needinfo?(alchen)

There are 40 total failures in the last 7 days on linux1804-64, macosx1014-64 debug

Recent failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=308560102&repo=autoland&lineNumber=2830

[task 2020-07-04T10:19:08.724Z] 10:19:08 INFO - TEST-START | browser/base/content/test/siteIdentity/browser_bug822367.js
[task 2020-07-04T10:19:08.766Z] 10:19:08 INFO - GECKO(1221) | [Child 1231: Main Thread]: I/DocShellAndDOMWindowLeak ++DOCSHELL 0x123a47c00 == 2 [pid = 1231] [id = {57cea926-5dae-d640-b6b8-11ff40994f39}]
[task 2020-07-04T10:19:08.767Z] 10:19:08 INFO - GECKO(1221) | [Child 1231: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 3 (0x123a7a7d0) [pid = 1231] [serial = 3] [outer = 0x0]
[task 2020-07-04T10:19:08.768Z] 10:19:08 INFO - GECKO(1221) | [Child 1231: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 4 (0x123c04000) [pid = 1231] [serial = 4] [outer = 0x123a7a7d0]
[task 2020-07-04T10:19:08.801Z] 10:19:08 INFO - GECKO(1221) | [Child 1231: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 5 (0x123c06c00) [pid = 1231] [serial = 5] [outer = 0x123a7a7d0]
[task 2020-07-04T10:19:08.905Z] 10:19:08 INFO - GECKO(1221) | [Child 1231, Main Thread] WARNING: NS_ENSURE_TRUE(info) failed: file /builds/worker/checkouts/gecko/extensions/permissions/PermissionDelegateHandler.cpp, line 351
[task 2020-07-04T10:19:08.906Z] 10:19:08 INFO - GECKO(1221) | [Child 1231: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 6 (0x123c8a000) [pid = 1231] [serial = 6] [outer = 0x123a7a7d0]

[task 2020-07-04T10:19:16.467Z] 10:19:16 INFO - GECKO(1221) | [Child 1231: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 21 (0x14e6c4000) [pid = 1231] [serial = 21] [outer = 0x14e65e430]
[task 2020-07-04T10:19:16.489Z] 10:19:16 INFO - GECKO(1221) | [Child 1223: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 3 (0x11e270f60) [pid = 1223] [serial = 5] [outer = 0x0] [url = https://example.com/browser/browser/base/content/test/siteIdentity/file_bug1045809_1.html]
[task 2020-07-04T10:19:16.522Z] 10:19:16 INFO - GECKO(1221) | Assertion failure: aTerminated || mDocument->GetReadyStateEnum() == Document::READYSTATE_LOADING (Bad readyState), at /builds/worker/checkouts/gecko/dom/base/nsContentSink.cpp:1420
[task 2020-07-04T10:19:16.531Z] 10:19:16 INFO - Initializing stack-fixing for the first stack frame, this may take a while...
[task 2020-07-04T10:19:31.378Z] 10:19:31 INFO - GECKO(1221) | #01: nsHtml5TreeOpExecutor::DidBuildModel(bool) [parser/html/nsHtml5TreeOpExecutor.cpp:173]
[task 2020-07-04T10:19:31.378Z] 10:19:31 INFO - GECKO(1221) | #02: nsHtml5TreeOpExecutor::FlushDocumentWrite() [parser/html/nsHtml5TreeOpExecutor.cpp:638]
[task 2020-07-04T10:19:31.378Z] 10:19:31 INFO - GECKO(1221) | #03: nsHtml5Parser::ParseUntilBlocked() [parser/html/nsHtml5Parser.cpp:581]
[task 2020-07-04T10:19:31.379Z] 10:19:31 INFO - GECKO(1221) | #04: nsHtml5TreeOpExecutor::RunFlushLoop() [parser/html/nsHtml5TreeOpExecutor.cpp:452]
[task 2020-07-04T10:19:31.379Z] 10:19:31 INFO - GECKO(1221) | #05: nsHtml5ExecutorReflusher::Run() [parser/html/nsHtml5TreeOpExecutor.cpp:0]
[task 2020-07-04T10:19:31.379Z] 10:19:31 INFO - GECKO(1221) | #06: mozilla::SchedulerGroup::Runnable::Run() [xpcom/threads/SchedulerGroup.cpp:146]
[task 2020-07-04T10:19:31.379Z] 10:19:31 INFO - GECKO(1221) | #07: mozilla::RunnableTask::Run() [xpcom/threads/TaskController.cpp:210]
[task 2020-07-04T10:19:31.379Z] 10:19:31 INFO - GECKO(1221) | #08: mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) [xpcom/threads/TaskController.cpp:459]
[task 2020-07-04T10:19:31.379Z] 10:19:31 INFO - GECKO(1221) | #09: mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) [xpcom/threads/TaskController.cpp:338]
[task 2020-07-04T10:19:31.379Z] 10:19:31 INFO - GECKO(1221) | #10: mozilla::TaskController::ProcessPendingMTTask() [xpcom/threads/TaskController.cpp:154]
[task 2020-07-04T10:19:31.379Z] 10:19:31 INFO - GECKO(1221) | #11: mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_5>::Run() [xpcom/threads/nsThreadUtils.h:578]
[task 2020-07-04T10:19:31.380Z] 10:19:31 INFO - GECKO(1221) | #12: nsThread::ProcessNextEvent(bool, bool*) [xpcom/threads/nsThread.cpp:1236]
[task 2020-07-04T10:19:31.380Z] 10:19:31 INFO - GECKO(1221) | #13: NS_ProcessNextEvent(nsIThread*, bool) [xpcom/threads/nsThreadUtils.cpp:513]
[task 2020-07-04T10:19:31.380Z] 10:19:31 INFO - GECKO(1221) | #14: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) [ipc/glue/MessagePump.cpp:87]
[task 2020-07-04T10:19:31.380Z] 10:19:31 INFO - GECKO(1221) | #15: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:310]
[task 2020-07-04T10:19:31.380Z] 10:19:31 INFO - GECKO(1221) | #16: nsBaseAppShell::Run() [widget/nsBaseAppShell.cpp:139]
[task 2020-07-04T10:19:31.380Z] 10:19:31 INFO - GECKO(1221) | #17: nsAppShell::Run() [widget/cocoa/nsAppShell.mm:694]
[task 2020-07-04T10:19:31.380Z] 10:19:31 INFO - GECKO(1221) | #18: XRE_RunAppShell() [toolkit/xre/nsEmbedFunctions.cpp:913]
[task 2020-07-04T10:19:31.381Z] 10:19:31 INFO - GECKO(1221) | #19: mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) [ipc/glue/MessagePump.cpp:237]
[task 2020-07-04T10:19:31.386Z] 10:19:31 INFO - GECKO(1221) | #20: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:310]
[task 2020-07-04T10:19:31.386Z] 10:19:31 INFO - GECKO(1221) | #21: XRE_InitChildProcess(int, char**, XREChildData const*) [toolkit/xre/nsEmbedFunctions.cpp:748]
[task 2020-07-04T10:19:31.386Z] 10:19:31 INFO - fix-stacks error: failed to read breakpad symbols dir /Users/cltbld/tasks/task_1593857471/build/symbols/plugin-container for /Users/cltbld/tasks/task_1593857471/build/application/Firefox NightlyDebug.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container
[task 2020-07-04T10:19:31.386Z] 10:19:31 INFO - fix-stacks note: this is expected and harmless for system libraries on debug automation runs
[task 2020-07-04T10:19:31.387Z] 10:19:31 INFO - GECKO(1221) | #22: main [/Users/cltbld/tasks/task_1593857471/build/application/Firefox NightlyDebug.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container + 0xf0b]
[task 2020-07-04T10:19:31.387Z] 10:19:31 INFO - GECKO(1221) | [Parent 1221, Unnamed thread 10804e540] WARNING: Resource acquired is being released in non-LIFO order; why?
[task 2020-07-04T10:19:31.387Z] 10:19:31 INFO - GECKO(1221) | : file /builds/worker/checkouts/gecko/xpcom/threads/BlockingResourceBase.cpp, line 292
[task 2020-07-04T10:19:31.387Z] 10:19:31 INFO - GECKO(1221) | --- Mutex : dumpSafetyLock (currently acquired)
[task 2020-07-04T10:19:31.387Z] 10:19:31 INFO - GECKO(1221) | calling context
[task 2020-07-04T10:19:31.387Z] 10:19:31 INFO - GECKO(1221) | [stack trace unavailable]

Alphan, did you by any change have the time to take a look?

Flags: needinfo?(alchen)

John, please help take a look this week. Thank you.

Flags: needinfo?(alchen) → needinfo?(jdai)
Assignee: alchen → nobody

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #13)

John, please help take a look this week. Thank you.

The test is executing document.close(), however, the document.readyState is still in the loading state due to location.reload() so that hit the assertion[1].

[1] https://searchfox.org/mozilla-central/rev/85ae3b911d5fcabd38ef315725df32e25edef83b/dom/base/nsContentSink.cpp#1418-1419

Flags: needinfo?(jdai) → needinfo?(emilio)
Flags: needinfo?(emilio) → needinfo?(jdai)

That patch only removed a null-check, the assertion was already there.

The ready state gets set to COMPLETE from here:

#0  mozilla::dom::Document::SetReadyStateInternal (this=0x7f6d5b3f8000, aReadyState=mozilla::dom::Document::READYSTATE_COMPLETE, aUpdateTimingInformation=false) at /builds/worker/workspace/build/src/dom/base/Document.cpp:11136
#1  0x00007f6d660e7ed6 in nsDocLoader::DocLoaderIsEmpty (this=0x7f6d5f1f6000, aFlushLayout=<optimized out>) at /builds/worker/workspace/build/src/uriloader/base/nsDocLoader.cpp:749
#2  0x00007f6d660e78ea in nsDocLoader::Stop (this=0x7f6d5f1f6000) at /builds/worker/workspace/build/src/uriloader/base/nsDocLoader.cpp:256
#3  0x00007f6d68e5a99b in nsDocShell::Stop (this=0x7f6d5f1f6000) at /builds/worker/workspace/build/src/docshell/base/nsDocShell.h:208
#4  nsDocShell::Stop (this=0x7f6d5f1f6000, aStopFlags=1) at /builds/worker/workspace/build/src/docshell/base/nsDocShell.cpp:4284
#5  0x00007f6d68e505de in nsDocShell::InternalLoad (this=0x7f6d5f1f6000, aLoadState=<optimized out>, aDocShell=<optimized out>, aRequest=<optimized out>) at /builds/worker/workspace/build/src/docshell/base/nsDocShell.cpp:9094
#6  0x00007f6d68e63966 in nsDocShell::LoadHistoryEntry (this=0x7f6d5f1f6000, aEntry=<optimized out>, aLoadType=2) at /builds/worker/workspace/build/src/docshell/base/nsDocShell.cpp:11374
#7  0x00007f6d68e711fc in nsDocShell::Reload (this=0x7f6d5f1f6000, aReloadFlags=<optimized out>) at /builds/worker/workspace/build/src/docshell/base/nsDocShell.cpp:4171
#8  0x00007f6d6672c837 in mozilla::dom::Location::Reload (this=<optimized out>, aForceget=false, aRv=...) at /builds/worker/workspace/build/src/dom/base/Location.cpp:583
#9  0x00007f6d669cb48c in mozilla::dom::Location_Binding::reload (cx=0x7f6d5f01b000, obj=..., void_self=0x7f6d5b3a6640, args=...) at LocationBinding.cpp:1141

So the question is what should happen, I guess. Henri, what should guarantee that the readystate assertion holds in this case?

Flags: needinfo?(hsivonen)

In the last 7 days there have been 23 occurrences on macosx1014-64 and linux1804-64 debug.

Recent failure: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=310259905&repo=mozilla-central&lineNumber=2420

This bug failed 42 times in the last 7 days on linux1804-64 and macosx1014-64 debug.

Recent failure log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=312421333&repo=autoland&lineNumber=5115

Whiteboard: [stockwell unknown] → [stockwell needswork:owner]

Might this be related to Document::NotifyAbortedLoad introduced with bug 1620679 ?

Flags: needinfo?(matt.woodrow)

(In reply to Jens Stutte [:jstutte] (REO for FF 81) from comment #26)

Might this be related to Document::NotifyAbortedLoad introduced with bug 1620679 ?

At least in the Pernosco trace that methods returns early and does not end up changing the readyState.

Flags: needinfo?(matt.woodrow)
Flags: needinfo?(hsivonen)

(In reply to Henri Sivonen (:hsivonen) from comment #27)

(In reply to Jens Stutte [:jstutte] (REO for FF 81) from comment #26)

Might this be related to Document::NotifyAbortedLoad introduced with bug 1620679 ?

At least in the Pernosco trace that methods returns early and does not end up changing the readyState.

Ah, the part of the method that does run is relevant after all! Good catch! Thanks!

Current hypothesis: document.open doesn't set mSetCompleteAfterDOMContentLoaded, which was added there, back to false.

Assignee: nobody → hsivonen
Status: NEW → ASSIGNED

The patch fixes a different bug than the one originally reported here. I'll mint a new bug number and move the patch.

Comment on attachment 9171653 [details]
Bug 1606499 - Reset mSetCompleteAfterDOMContentLoaded in Document::Open().

Revision D88008 was moved to bug 1660764. Setting attachment 9171653 [details] to obsolete.

Attachment #9171653 - Attachment is obsolete: true

Filed bug 1660764.

Assignee: hsivonen → nobody
Status: ASSIGNED → NEW

(In reply to Henri Sivonen (:hsivonen) from comment #30)

The patch fixes a different bug than the one originally reported here. I'll mint a new bug number and move the patch.

As this still triggers quite often: Any idea how to proceed here?

Flags: needinfo?(jdai) → needinfo?(hsivonen)

I think the bug is that location.reload() doesn't perform step 11 of "navigate" properly: It should abort the parser. Then, document.close() should return early due to there not being an active script-created parser.

Flags: needinfo?(hsivonen)

The code has a comment about not firing the load event. Let's see if tests fail when doing a proper abort:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=9bc13c60149ebc0394f86f884ac9e7488db5825f

Blame seems to point to bug 1489308. I'm surprised. I assume bz had some reason not to call StopDocumentLoad().

Regressed by: 1489308
Has Regression Range: --- → yes
Assignee: nobody → hsivonen

I assume bz had some reason not to call StopDocumentLoad()

I don't think it came up. I based this code on nsDocumentViewer::LoadComplete, as I recall, which obviously doesn't do that...

It's worth checking whether the spec needs to say something about this situation; I've more or less paged this stuff out, so can't comment on it intelligently without a bunch of digging.

Pushed by hsivonen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/28132cc84517
Abort document on location.reload(). r=smaug

(In reply to Boris Zbarsky [:bzbarsky] from comment #40)

I assume bz had some reason not to call StopDocumentLoad()

I don't think it came up.

Thanks.

It's worth checking whether the spec needs to say something about this situation; I've more or less paged this stuff out, so can't comment on it intelligently without a bunch of digging.

AFAICT, the spec says "abort" per comment 35. The existing corpus of test cases appears to tolerate an abort here.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: