Closed Bug 1278919 Opened 4 years ago Closed 4 years ago

Page is not completely loaded

Categories

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

49 Branch
x86_64
Windows 7
defect
Not set

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)

Attached image Bad.png
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
Attached image Good.png
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.
Component: Networking → DOM
Boris, any thoughts here?
Flags: needinfo?(bzbarsky)
Whiteboard: btpp-followup-2016-06-15
Via local build,
Last Good: 796bb8ece8c3
First Bad: add719ee5b2f
Blocks: 1268957
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.
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.  :(
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: nobody → bzbarsky
Status: NEW → ASSIGNED
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 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+
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
https://hg.mozilla.org/mozilla-central/rev/e50f5587a7ef
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
Verified as fixed on Windows 7 on the latest Nightly 50 (Build ID:20160612030220)- Page is completely loaded
Status: RESOLVED → VERIFIED
[Tracking Requested - why for this release]:
Version: 50 Branch → 49 Branch
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+
Tracking 49+ to address this page loading issue.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.