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)
Tracking
()
People
(Reporter: tsmith, Assigned: hsivonen)
References
(Blocks 1 open bug, Regression)
Details
(4 keywords, Whiteboard: [stockwell unknown])
Attachments
(2 files, 1 obsolete file)
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
Reporter | ||
Comment 1•3 years ago
|
||
A Pernosco session is available here: https://pernos.co/debug/l4K5PT7xY6Dyw01aFBkd8w/index.html
Comment 2•3 years ago
|
||
(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.
Comment 3•3 years ago
|
||
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.
- Did some document operation.
- 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.
Updated•3 years ago
|
![]() |
||
Updated•3 years ago
|
Comment hidden (Intermittent Failures Robot) |
Comment 5•3 years ago
|
||
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?
Comment hidden (Intermittent Failures Robot) |
Comment 7•3 years ago
|
||
Currently, I am occupied by other urgent tasks and won't have immediate action right now.
Keep an eye on this failure first.
Comment hidden (Intermittent Failures Robot) |
Comment 9•3 years ago
|
||
There are 24 total failures in the last 7 days: https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?startday=2020-06-19&endday=2020-06-26&tree=trunk&bug=1606499
Recent failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=307670394&repo=autoland&lineNumber=2295
Comment hidden (Intermittent Failures Robot) |
Comment 11•3 years ago
|
||
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?
Comment hidden (Intermittent Failures Robot) |
Comment 13•3 years ago
|
||
John, please help take a look this week. Thank you.
Updated•3 years ago
|
Comment 14•3 years ago
•
|
||
(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].
Updated•3 years ago
|
Comment 15•3 years ago
|
||
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?
Comment hidden (Intermittent Failures Robot) |
Comment 17•3 years ago
|
||
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
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 21•3 years ago
|
||
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
Updated•3 years ago
|
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Assignee | ||
Comment 24•3 years ago
|
||
Caught in Pernosco! https://pernos.co/debug/-ukMnEseJEYvX_BAeKZTow/index.html
Comment hidden (Intermittent Failures Robot) |
Comment 26•3 years ago
|
||
Might this be related to Document::NotifyAbortedLoad introduced with bug 1620679 ?
Assignee | ||
Comment 27•3 years ago
|
||
(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
.
Assignee | ||
Comment 28•3 years ago
|
||
(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 | ||
Comment 29•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Comment 30•3 years ago
|
||
The patch fixes a different bug than the one originally reported here. I'll mint a new bug number and move the patch.
Comment 31•3 years ago
|
||
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.
Assignee | ||
Comment 32•3 years ago
|
||
Filed bug 1660764.
Comment hidden (Intermittent Failures Robot) |
Comment 34•3 years ago
|
||
(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?
Assignee | ||
Comment 35•3 years ago
|
||
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.
Assignee | ||
Comment 36•3 years ago
|
||
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
Assignee | ||
Comment 37•3 years ago
|
||
Assignee | ||
Comment 38•3 years ago
|
||
Blame seems to point to bug 1489308. I'm surprised. I assume bz had some reason not to call StopDocumentLoad()
.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 39•3 years ago
|
||
With both the readyState change and the abort:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e995452e8f142fc9da11eccd46e1005839a8826a
![]() |
||
Comment 40•3 years ago
|
||
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.
Comment 41•3 years ago
|
||
Pushed by hsivonen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/28132cc84517 Abort document on location.reload(). r=smaug
Assignee | ||
Comment 42•3 years ago
|
||
(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.
Comment 43•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Description
•