-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<object>
without "data" attribute probably needs to consider params to figure out its URL
#387
Comments
Here's where this happens in Blink: As @bzbarsky noted, there are four forms recognized: Is there any point in investigating the compat risk for this, or should we just spec all four forms? |
Maybe we only need those that are used for embedding Flash? http://webdevdata.org/ data set 2015-01-08 (780 Mb) 87,000 pages
Most of these have an
(1 site embedding Java, 1 site embedding Flash, 1 site embedding WMP.) |
Well, if anyone wants to avoid adding more cases than necessary, I can measure how often each is encountered in Blink, but that would add a lot of waiting to the process. |
My thinking was that nobody cares about non-Flash, given that Blink dropped https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/ The data in webdevdata suggests |
We should really figure out what Edge does here. |
@travisleithead @jacobrossi, ideas? |
I tested IE11 on Win7, and it looks like only Spec'ing only |
If you create a quick test case I can do Edge, in case they have decided to increase interop by implementing a couple more. (When I wake up. Going to sleep now, for realz!) |
Good luck with that sleep thing. |
Looks like the same in Edge as IE11: movie and src only. |
OK so let's spec movie and src.
It appears this only works if the URL ends with ".swf" (the spec has something about this as well for both Should we check for dynamic changes to
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3845 ... probably yes. |
Probably less critical in terms of compat, so it depends on whether we're viewing this as a "thing we should support and make nice" or a "thing we're adding just so sites don't break, make it simple".
Or some other type handled by a plug-in, at least in Chrome. Are we adding |
@mfreed7 would you be up for adding a use counter for when https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_object_element.cc;l=148;drc=fb62432bab790c4f6006a4ce04084e214fd2d302;bpv=1;bpt=1 is hit for PDFs because of |
See [1] for context, but there is interest in deprecating the ability to specify an <object> containing a <param> element that specifies the URL (via a name in {"code","data","movie", "src", or "url"}). This CL adds a use counter for that feature. [1] whatwg/html#387 Bug: 572908 Change-Id: I7f152d05d992606224fb895bca6cd65a4bca15ea Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3139401 Commit-Queue: Mason Freed <masonf@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#918305}
Use counter added. I'll try to check back here in a bit when data is available. |
Ok, early data says that usage of |
Thanks for looking into it! It's possible a more sophisticated use counter could drive that number down (e.g., compute the URL with and without that logic to see if any Firefox fallback code would take over; or, be sure to only include PDF, and not any NaCl cases or similar). But probably we should just proceed with speccing the 2/3 browser behavior here, since the wins from the simpler 1/3 browser behavior are mostly for theoretical purity and spec authors, whereas a nontrivial deprecation imposes costs on implementers and web developers and users. I can try working on that after vacation. Presumably we'll still get some good simplifications if this is the only impact param can have. |
Ping @mfreed7 on those HTTP archive checks, ideally before the next triage meeting on Thursday :) |
Thanks for the ping. So I took a look at this:
So while I did the HTTP Archive search, I don't really trust the results at all. I'm thinking we have two options:
I'm leaning toward #2, but it's a more risky approach. Thoughts? |
Ok, from the triage discussion, I took the action item to post the list of what I found on the HTTP Archive search. Please see the link below, which contains about 50 random examples I found. I took some time and went through the first ~20 or so to see what they were doing. There do appear to be a couple packages that people are using which would break, plus at least one that didn't look like it was from a package (or was a one-off). There are also a number of examples where there is a TL;DR I think there might be real compat issues with PDFs. But see what you think. |
I took a quick look at several of those pages and couldn't find any smoking gun broken site. Note that several of the "red" rows for var objbuilder = '<div class="flex-video"><object width="100%" height="100%" data="data:application/pdf;base64,' + data.content + '" type="application/pdf" name="brochure">';
objbuilder += '<param name="src" value="data:application/pdf;base64,' + data.content + '">';
objbuilder += '</object></div>'; which falls back correctly. Similarly I tried to go to a few homepages that use RD3 and they seem to just be including lots of RD3 libraries; I'm not sure they actually use the PDFPrint.js file. So, it's still not clear to me whether this simplification is worth the risk, but I guess so far I still think it might work. I will say that if you wanted to create a more comprehensive use counter for (1) what I would do is:
|
So I finally got a chance to get back to this and add such a use counter. And I re-discovered what I commented about above:
Therefore the existing counter actually does seem to be counting instances where the So the only thing the existing use counter counts that it shouldn't would be a Comments appreciated. I think we should discuss our plan of action assuming the current (trending downward) 0.04% actually represents usage that we'll break by deprecating |
So two new use counters have been added for this case. Both still only count (as above) when the containing
These just landed, so it'll take a few months for data to show up. |
Quick update: still no data. |
Checking back in again here. The use counters in the comment above landed in Chrome 99.0.4832.0, which was in stable for most of March. The use counters show roughly this:
So the vast majority (99.95%) of If the above number are correct, it would seem "ok" to move ahead with deprecation. |
Thank you, that sounds very promising! \o/ (I suspect we'd still have to support |
Given that plugins are gone from the web platform (with their full removal from the spec being tracked in #6003), it is not useful. In some browsers it can be used to figure out the URL of an <object>, even when that <object> is not being used for a plugin, via params named "movie", "src", "code", or "url". But we decided to remove this behavior from browsers instead of specifying it. This retains the HTMLParamElement interface, as well as the parser behavior of <param>. Closes #387. Helps with #6003.
I have posted a spec PR for this at #7816 and hope we can proceed with the removal in Chromium soon. |
Given that plugins are gone from the web platform (with their full removal from the spec being tracked in #6003), it is not useful. In some browsers it can be used to figure out the URL of an <object>, even when that <object> is not being used for a plugin, via params named "movie", "src", "code", or "url". But we decided to remove this behavior from browsers instead of specifying it. This retains the HTMLParamElement interface, as well as the parser behavior of <param>. Closes #387. Helps with #6003.
Given that plugins are gone from the web platform (with their full removal from the spec being tracked in whatwg#6003), it is not useful. In some browsers it can be used to figure out the URL of an <object>, even when that <object> is not being used for a plugin, via params named "movie", "src", "code", or "url". But we decided to remove this behavior from browsers instead of specifying it. This retains the HTMLParamElement interface, as well as the parser behavior of <param>. Closes whatwg#387. Helps with whatwg#6003.
See [1] for context, but there is interest in deprecating the ability to specify an <object> containing a <param> element that specifies the URL (via a name in {"code","data","movie", "src", or "url"}). This CL adds a use counter for that feature. [1] whatwg/html#387 Bug: 572908 Change-Id: I7f152d05d992606224fb895bca6cd65a4bca15ea Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3139401 Commit-Queue: Mason Freed <masonf@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#918305} NOKEYCHECK=True GitOrigin-RevId: 8d40b3335c5e54869d4ffec5108f997753152be0
Just a quick check-in on that process. I've been very slowly rolling out this change in Chromium, and I'm about to increase from 2% of stable to 5% of stable. But at this point, things are looking good: no reported bugs. I'll keep going slowly with the rollout, but I just wanted to say so far, so good. I'll stop commenting in this issue, but will continue updating the Chromium tracking bug. Of course, if a compat issue is reported, I'll report back here and re-open this bug. |
Consider this testcase:
This apparently (according to https://bugzilla.mozilla.org/show_bug.cgi?id=517440#c0) loads test.swf in IE, Blink, and WebKit. Per spec, and in Firefox, it does not.
This param is NOT processed by Flash itself afaict. If it's getting loaded at all, it's the browser doing it. So the spec should probably specify this behavior, since most browsers do it.
It's worth figuring out what the actual required behavior here is, by the way. Today I ran into a page that had this markup on it:
(note no
type
attribute) and WebKit/Blink happily loaded that as Flash. Neither IE nor Firefox did. I looked at the Blink code for this, and its behavior is summarized in https://bugzilla.mozilla.org/show_bug.cgi?id=517440#c2, assuming I understood it correctly.So at the very least we need to figure what set of param names reliably gets treated as a url in IE. We also need to figure out whether we want the Blink/WebKit behavior of using a type sniffed from a param-provided URL if no type is specified. Seems like that would at least be consistent with what happens if no type is specified by the
data
attribute is specified.The text was updated successfully, but these errors were encountered: