No problem! So here too, I think I have an answer for you. As part of the
discussion around deprecating this functionality, I did exactly that: an
HTTP Archive search for <object> containing <param>. See this comment
<https://github.com/whatwg/html/issues/387#issuecomment-961271400>, which
links to this spreadsheet
<https://docs.google.com/spreadsheets/d/1Fo3F6IIOMFbXH116Y22950CSSksvuRLLwO3c5Kn8E90/edit?resourcekey=0-U-u5Uecsr9aK2S-CWSwPDg#gid=1743741361>
with
results. Also, importantly, see this reply comment
<https://github.com/whatwg/html/issues/387#issuecomment-961362808> with
more analysis.

The TL;DR is that in the end, we did not find any issues with the top ~20
sites we found. And while we were looking only for PDF-related params,
that's all that Chromium currently supports anyway, so that should be all
we're capable of breaking.

LMK if the above satisfies your desire to do more spot checking, or if
you'd prefer I look deeper.

Thanks,
Mason


On Fri, Apr 15, 2022 at 1:52 PM Mike Taylor <[email protected]> wrote:

> Oh cool, I didn't notice the fallback iframe or embed, thanks for pointing
> that out! I think just to be on the safe side, searching HTTP Archive for a
> list of sites that have an <object> with non-swf <param> values would be
> nice to look at, and we could spot check a small pile to ensure this
> fallback pattern holds and we're not breaking video playback on sites that
> may not be maintained.
>
> On 4/15/22 2:31 PM, Mason Freed wrote:
>
> Thanks for digging into the example sites there! So I looked further into
> the two examples you gave, and I think what's actually going on in both
> cases is that the <object> also contains fallback content which is what
> you're seeing:
>
> For http://sextherapy.ru/, the full <object> looks like this:
>
>   <object width="180" height="100"
>           classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
>           codebase="
> http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0
> ">
>     <param name="allowFullScreen" value="true" />
>     <param name="allowscriptaccess" value="always" />
>     <param name="src" value="//
> www.youtube.com/v/7wQYLXBX2RQ?version=3&amp;hl=ru_RU&amp;rel=0" />
>     <param name="allowfullscreen" value="true" />
>     <embed width="180" height="100" type="application/x-shockwave-flash"
>            src="//
> www.youtube.com/v/7wQYLXBX2RQ?version=3&amp;hl=ru_RU&amp;rel=0"
>            allowFullScreen="true" allowscriptaccess="always"
> allowfullscreen="true" />
>   </object>
>
> The <param>s in this example aren't actually doing anything - you can
> remove them and still see the video, since it's provided by the fallback
> <embed>. It looks like those params were maybe meant to talk to an SWF
> object?
>
> Similarly, for https://jackrussell.forumattivo.com/, the <object> is this:
>   <object width="560" height="340">
>     <param name="movie" value="
> https://www.youtube.com/v/_ikcScPyKUQ&hl=it&fs=1&";></param>
>     <param name="allowFullScreen" value="true"></param>
>     <param name="allowscriptaccess" value="always"></param>
>     <iframe  width="560" height="315" src="
> https://www.youtube.com/embed/_ikcScPyKUQ";
>            frameborder="0" allowfullscreen=""></iframe>
>   </object>
>
> Again, the <param>s aren't doing anything here, and the fallback <iframe>
> contains the "real" content.
>
> I also confirmed that with the proposed behavior disabled (i.e. <param>s
> can't provide URLs), both example sites still work.
>
> I'm happy to look further into other such examples if you like, but I
> think these two examples should be "ok".
>
> Again, thanks for taking a look!
>
> Thanks,
> Mason
>
>
>
> On Fri, Apr 15, 2022 at 11:06 AM Mike Taylor <[email protected]>
> wrote:
>
>> On 4/13/22 12:48 PM, Mason Freed wrote:
>>
>> Contact emails [email protected]
>>
>> Explainer https://github.com/whatwg/html/pull/7816
>> https://github.com/whatwg/html/issues/6003
>>
>> Specification https://github.com/whatwg/html/pull/7816
>>
>> Summary
>>
>> The <param> element can be used to specify parameters such as a URL (via
>> params named "movie", "src", "code", "data", or "url") to a containing
>> <object> element. Given the removal of plugins from the web platform, and
>> the relative lack of use of this particular functionality, we would like to
>> deprecate and remove it.
>>
>>
>> Blink component Blink
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>
>> Motivation
>>
>> Given that plugins are gone from the web platform (with their full
>> removal from the spec being tracked in
>> https://github.com/whatwg/html/issues/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", "data", 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>.
>>
>>
>> Initial public proposal
>>
>> Search tags <param> <https://chromestatus.com/features#tags:%3Cparam%3E>
>> , <object> <https://chromestatus.com/features#tags:%3Cobject%3E>
>>
>> TAG review
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Gecko: Shipped/Shipping (
>> https://github.com/whatwg/html/issues/387#issuecomment-1088331300) Issue
>> was initially raised by Mozilla, and Gecko already does not process param
>> at all.
>>
>> WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=239188) No
>> response on the bug yet.
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>> Ergonomics
>>
>> Since this is a deprecation, there is a Web Compat risk. I added use
>> counters for the situations that will be affected: - <param> that specifies
>> a URL, inside an <object> that doesn't: 0.04%,
>> https://chromestatus.com/metrics/feature/timeline/popularity/4010 - As
>> above, but URL successfully resolves to a (supported) PDF resource:
>> 0.00002%,
>> https://chromestatus.com/metrics/feature/timeline/popularity/4110 - As
>> above, but URL successfully resolves to an (unsupported) non-PDF resource:
>> not measurable,
>> https://chromestatus.com/metrics/feature/timeline/popularity/4111 So the
>> vast majority (99.95%) of <param> URL usage appears to point to invalid
>> resources - likely mostly Flash. A very small percentage (0.05% of
>> <param>-with-URL usage, 0.00002% of web page loads) are likely to break
>> when we deprecate this functionality.
>>
>> I clicked on the first 20 results from
>> https://chromestatus.com/metrics/feature/timeline/popularity/4010
>> (careful, 1 is NSFW), and 18 contain busted SWFs. But two of them are
>> embedding youtube videos via <param>:
>>
>> https://jackrussell.forumattivo.com/ has an <object> that has a child
>> param name="movie" value=
>> "https://www.youtube.com/v/_ikcScPyKUQ&hl=it&fs=1&";
>> <https://www.youtube.com/v/_ikcScPyKUQ&hl=it&fs=1&;>>.
>>
>> http://sextherapy.ru/ (SFW-ish, at least on the homepage)<param
>> name="src" value="//
>> www.youtube.com/v/7wQYLXBX2RQ?version=3&amp;hl=ru_RU&amp;rel=0" />
>>
>> I had no idea that was possible - can we dig in some more to see how many
>> params have a value with "youtube.com", to see if I got lucky and found
>> the only 2, or if a lot of sites are relying on this behavior?
>>
>>
>>
>> WebView Application Risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>>
>> Debuggability
>>
>> Deprecation.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>> ? Yes
>>
>> Flag name
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/1315717
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6283184588193792
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.com/>.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhXTo%3Dg3scg7KF8g%3Dn5a4rA%3D6UD5cAxTBn9HetnAO%2BJ-A%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhXTo%3Dg3scg7KF8g%3Dn5a4rA%3D6UD5cAxTBn9HetnAO%2BJ-A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjtEVxLRybAh6_3k92Qc-0OTQJbZy1c5JSjTY3vTpnYOA%40mail.gmail.com.

Reply via email to