Closed
Bug 1278919
Opened 8 years ago
Closed 8 years ago
Page is not completely loaded
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
FIXED
mozilla50
Tracking | Status | |
---|---|---|
firefox48 | --- | unaffected |
firefox49 | + | fixed |
firefox50 | --- | verified |
People
(Reporter: roxana.leitan, Assigned: bzbarsky)
References
Details
(Whiteboard: btpp-followup-2016-06-15)
Attachments
(3 files)
58.90 KB,
image/png
|
Details | |
483.06 KB,
image/png
|
Details | |
1.54 KB,
patch
|
ckerschb
:
review+
lizzard
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0 [Affected versions]: Nightly 50.0a1 [Steps to reproduce]: 1.Open https://www.chromeexperiments.com/experiment/3d-periodic-table 2.Click "Launch experiment" [Expected results]: 1.Page is loaded and all content is displayed(see the attached screenshot "Good") 2.http://graphoverflow.com/graphs/3d-periodic-table.html page is opened in a new tab [Actual results]: 1.Page is partially loaded(see the attached screenshot "Bad") 2.The page from step 1 is reopened in a new tab [Regression range]: Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fcedd1 b3ef255d38681ab5e2745e45eaea926fb6&tochange=add719ee5b2f0f3475f2aa5f7c4cbdb861b1 86f7 [Notes] 1.This is what appears in Browser Console: A call to document.write() from an asynchronously-loaded external script was ignored.elements.vulcanized.min.js:10:165 A call to document.write() from an asynchronously-loaded external script was ignored.elements.vulcanized.min.js:10:165 HierarchyRequestError: Node cannot be inserted at the specified point in the hierarchy webcomponents.js:1809 A call to document.write() from an asynchronously-loaded external script was ignored.elements.vulcanized.min.js:10:165 HierarchyRequestError: Node cannot be inserted at the specified point in the hierarchy webcomponents.js:1809 A call to document.write() from an asynchronously-loaded external script was ignored.elements.vulcanized.min.js:10:165 HierarchyRequestError: Node cannot be inserted at the specified point in the hierarchy webcomponents.js:1809 TypeError: Polymer.flush is not a function [Learn More]elements.vulcanized.min.js:425:33 TypeError: Polymer.flush is not a function [Learn More]elements.vulcanized.min.js:425:33 TypeError: Polymer.flush is not a function [Learn More]elements.vulcanized.min.js:425:33 TypeError: Polymer.flush is not a function [Learn More]elements.vulcanized.min.js:425:33 TypeError: Polymer.flush is not a function [Learn More]elements.vulcanized.min.js:425:33 TypeError: Polymer.flush is not a function [Learn More]elements.vulcanized.min.js:425:33 TypeError: Polymer.job is undefined [Learn More]elements.vulcanized.min.js:438:103 2.The issue also is reproducible on Windows 10 X64
Comment 2•8 years ago
|
||
Regression range link: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fcedd1b3ef255d38681ab5e2745e45eaea926fb6&tochange=add719ee5b2f0f3475f2aa5f7c4cbdb861b186f7 If the range is right, I would assume that bug 1268957 or bug 1276112 are responsible. All I see is a blank page on a 6/6 nightly, however.
Updated•8 years ago
|
Component: Networking → DOM
Comment 3•8 years ago
|
||
Boris, any thoughts here?
Flags: needinfo?(bzbarsky)
Whiteboard: btpp-followup-2016-06-15
Comment 4•8 years ago
|
||
Via local build, Last Good: 796bb8ece8c3 First Bad: add719ee5b2f
Blocks: 1268957
Assignee | ||
Comment 5•8 years ago
|
||
I'll try to look in more detail tomorrow, but my initial guess is that Polymer is just buggy (e.g. see bug 1256031 for another example), but the bug is being hidden in Chrome because they implement the web components pieces involved and don't run the relevant Polymer code.
Assignee | ||
Comment 6•8 years ago
|
||
In particular, I managed to reproduce hitting the code I added in bug 1268957 precisely once so far. The other times I've loaded this page it either loads completely fine or goes into an infinite loop akin to bug 1256031. All of it seems pretty timing-dependent. :(
Assignee | ||
Comment 7•8 years ago
|
||
OK, I reproduced the error event being fired again. It's being fired for a stylesheet whose URI is "https://fonts.googleapis.com/css?family=Source+Sans+Pro:200,300|Lato:100|Source+Code+Pro:300,400,500,600,700". Looks like the load is blocked by nsDataDocumentContentPolicy. In a data document we really shouldn't be doing loads to start with; arguably we should not fire an error event for those. Not doing that fixes the page.
Assignee | ||
Comment 8•8 years ago
|
||
Attachment #8761477 -
Flags: review?(ckerschb)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•8 years ago
|
||
Comment on attachment 8761477 [details] [diff] [review] Don't fire error events on <link rel='stylesheet'> when its loading is blocked in a data document; the fact that we even _try_ to load in that situation is bizarre Approval Request Comment [Feature/regressing bug #]: Bug 1268957 [User impact if declined]: Some sites will be broken [Describe test coverage new/current, TreeHerder]: Hard to add a non-racy test for this, because it requires asserting that an event is not fired... [Risks and why]: Fairly low risk. Just disables the change from bug 1268957 in certain situations. [String/UUID change made/needed]: None.
Flags: needinfo?(bzbarsky)
Attachment #8761477 -
Flags: approval-mozilla-aurora?
Comment 10•8 years ago
|
||
Comment on attachment 8761477 [details] [diff] [review] Don't fire error events on <link rel='stylesheet'> when its loading is blocked in a data document; the fact that we even _try_ to load in that situation is bizarre Review of attachment 8761477 [details] [diff] [review]: ----------------------------------------------------------------- Thanks, r=me
Attachment #8761477 -
Flags: review?(ckerschb) → review+
Comment 11•8 years ago
|
||
Pushed by bzbarsky@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/e50f5587a7ef Don't fire error events on <link rel='stylesheet'> when its loading is blocked in a data document; the fact that we even _try_ to load in that situation is bizarre. r=ckerschb
Comment 12•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/e50f5587a7ef
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
Reporter | ||
Comment 13•8 years ago
|
||
Verified as fixed on Windows 7 on the latest Nightly 50 (Build ID:20160612030220)- Page is completely loaded
Status: RESOLVED → VERIFIED
Comment 14•8 years ago
|
||
[Tracking Requested - why for this release]:
status-firefox48:
--- → unaffected
status-firefox49:
--- → affected
tracking-firefox49:
--- → ?
Version: 50 Branch → 49 Branch
Comment 15•8 years ago
|
||
Comment on attachment 8761477 [details] [diff] [review] Don't fire error events on <link rel='stylesheet'> when its loading is blocked in a data document; the fact that we even _try_ to load in that situation is bizarre Regression from 49, makes sense to uplift this fix so as not to load pages when we shouldn't
Attachment #8761477 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 17•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/96cf57b4015f
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•