PDF loading examples

[annevk]

These examples show that Firefox and Safari ignore Content-Type for a variety of loading scenarios whereas Chrome appears to require application/pdf consistently. (Chrome does instantiate the PDF plugin container in more cases, but that then fails to load the PDF.)

Given this, it seems to me there's an opportunity to require application/pdf going forward.

(Note that you cannot count on the test results. I'm not really sure how to test this yet.)

I created this to investigate whatwg/html#6003.

@domenic @youennf @rwlbuis thoughts?

[domenic]

How much of this is web observable? In particular I'm curious about

Chrome does instantiate the PDF plugin container in more cases, but that then fails to load the PDF.

I take it from

Note that you cannot count on the test results. I'm not really sure how to test this yet.

maybe none of it is observable yet, or at least you haven't figured out how.

Hmm, maybe a PDF that embeds an image request, which hits the server? Then the server could tell is if that endpoint was hit? I have no idea how to create such a PDF, but I imagine it's possible...

[annevk]

So this is observable to some extent with respect to whether fallback is shown for the embed/object elements and whether they take up space. Or whether a download is generated. And perhaps also whether they end up with a nested browsing context or not. We'll need to decide what we want to happen here going forward as some of this is legacy from the plugin-era we deferred cleaning up. With a clearer idea about that I can probably assert a bit more here.

(Your idea is interesting though and something we might need as well. The other alternative might be using reference tests. But again, we first need to decide on what we want.)

[davidp3]

So this is observable to some extent with respect to whether fallback is shown for the embed/object elements and whether they take up space. Or whether a download is generated. And perhaps also whether they end up with a nested browsing context or not.

HTML fallbacks could work for <object>s -- there is mild inconsistency around how e.g. Firefox and Safari handle sandboxed and invalid pdfs but that can be normalized. I don't know if <object> HTML fallbacks are on the chopping block -- they do still seem useful for pdfs (and nothing else). And that obviously wouldn't work for <embed>s.

Recording requests for files referenced in the pdf could work if that is possible but I don't know that it is. (Clickable) links in the pdf are an option but that gets messy. If APIs get added for things like PDF support discovery then maybe an event indicating a PDF was loaded (or not) would also be warranted.

[domenic]

I tried briefly to convert these into real tests. Interestingly it looks like Chrome does not display fallback content inside these objects. The failures are also quite variable, sometimes displaying the content as text, sometimes displaying "Error / Failed to load PDF document.", and sometimes displaying a blank white square (with a border for an iframe). In all cases Chrome takes up 300x150 space.

If I change the setting:

then the result is that cases which would previously display a PDF successfully, or would say "Error / Failed to load PDF document", instead display a download button:

although I suspect the behavior is different for top-level browsing contexts.

So, I'm less hopeful about achieving full interop here. It would take some effort on everyone's part.

Oh, and if we were to convert these into real tests, I think they would need to be reftests to account for Chrome's behavior, because the lack of fallback content means you can't use getBoundingClientRect() or similar.