On Fri, Apr 15, 2022 at 2:17 PM Mike Taylor <[email protected]> wrote:
> Fantastic - nice work on the compat analysis. LGTM. > Thanks! > On 4/15/22 5:02 PM, Mason Freed wrote: > > 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&hl=ru_RU&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&hl=ru_RU&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&hl=ru_RU&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%3DNeDg6ZHCp6Ty%2BOAJab8cC94aXK8k5z6yq7sq2eFvj_8S5xw%40mail.gmail.com.
