1351652 - Object element sends extra requests

Status: REOPENED

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

Description

[Sergiy Uvarov]

Attachment: firefox.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170323105023

Steps to reproduce:

We have a popup to show a pdf document. When the user clicks the link the application updates the part of the page with object element.


Actual results:

The object element loads a pdf document and then makes extra get to the server to load xhtml. And the browser show the error dialog (see attachment).
This functionality stopped working in 49.0 version.


Expected results:

The object element loads a pdf document without extra queries or no errors should be shown.

Comment 1

[Loic]

Sergiy, could you provide a reduced testcase, or a live testcase (on a testing server e.g.).

Comment 2

[Sergiy Uvarov]

(In reply to Loic from comment #1)
> Sergiy, could you provide a reduced testcase, or a live testcase (on a
> testing server e.g.).

Sorry for not answering for a long time.

Our testing server: http://dev1.isddesign.com:9080/jsf/billing/billing.xhtml
Login: [e-mail]
I will send to the password by email.

Steps:
1. Select tab "Invoices"
2. Click on the last icon in a row and you will receive this error.

Comment 3

[Loic]

Ty for the testcase, I'm able to see the error with FF52. I'll try to narrow down a regression range if it regressed after FF49.

Comment 4

[Loic]

Well, the issue appears only with e10s (multiprocess) enabled. I can even reproduce it with FF42 and e10s on.

Workaround: open the page about:config and set to false both strings browser.tabs.remote.autostart and browser.tabs.remote.autostart.2 (restart Firefox to apply).

Error message:
XML Parsing Error: no root element found
Location: http://dev1.isddesign.com:9080/javax.faces.resource/dynamiccontent.properties.xhtml?ln=primefaces&v=6.0&pfdrid=8c69ebc4-0a18-4022-9193-f5333cbe553c&pfdrt=sc&pfdrid_c=true
Line Number 1, Column 1:  dynamiccontent.properties.xhtml:1:1

This error appears when clicking on tab "Invoices" and on the icon to display the PDF.
No such error with e10s disabled.

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The impact of this regression seems obvious... I apparently don't know who could help answer why enabling e10 triggers an extra loading for xhtml. Olli, do you have any ideas of what's up here or could you point me to the right person for this question? Thanks.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

mystor and qdot seem to have done some object element related stuff recently.

Comment 7

[Nika Layzell [:nika] (ni? for response)]

(In reply to Olli Pettay [:smaug] from comment #6)
> mystor and qdot seem to have done some object element related stuff recently.

I don't know very much about this logic - I imagine that qdot will have a better idea of what might have caused this.

Comment 8

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

I'm not sure how we'd just know to call into a Java EE UI library without context (the primefaces call listed in comment #4), so I'm guessing there may be something about how object tags are formed on this website. Can you email me the test login for the website so I can investigate further?

Comment 9

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Ok, checked this out on this test site, thanks for the login info.

From what I can tell, the problem isn't that the object tag is sending extra requests, but rather that we're requesting an XHTML document as the data tag, which is handing back a null document. That's not valid XHTML, though firefox is the only ones that yell about that. If you just create a test.xhtml document with nothing in it and try to open it, safari/chrome/edge will just show either a blank page or try to display the XML tree, while firefox throws the same "missing root" error.

Comment 10

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Unmarking e10s on this, as I can replicate this in both non-e10s and e10s. This is an XML parser handling issue, shouldn't have anything to do with multi-process.

We're now trying figure out how we should deal with null blocks sent to the XML parser. Will update bug title and comments as we figure out if/where we want to go with this.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Per spec, for XML loaded in an iframe, UAs may, but are not required to, show parse errors.

Empty document is _definitely_ a parse error, though, and UAs interoperably show it as such via DOMParser, for what it's worth....

Comment 12

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Marking this as invalid. We can't help that we're getting back an invalid document that other browsers will accept.

Comment 13

[Sergiy Uvarov]

(In reply to Kyle Machulis [:qdot] [:kmachulis]  (PTO until May 30) (if a patch has no decent commit message, automatic r-) from comment #12)
> Marking this as invalid. We can't help that we're getting back an invalid
> document that other browsers will accept.

The problem is not in an invalid document, the problem is that FF after loading document sends an extra wrong request to the server. Other browsers just load a document without any extra requests.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Kyle, could you check this again?  In particular, why is the e10s vs non-e10s behavior different, per comment 4?

Comment 15

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

See comment #10, where I did not experience the split e10s/non-e10s issue. That said, yeah, I'll try it one more time, but I don't remember seen an extra load when I tested this last time, which is why I invalidated it in the first place.