LGTM3 On Fri, Apr 15, 2022, 23:24 Chris Harrelson <[email protected]> wrote:
> LGTM2 > > On Fri, Apr 15, 2022 at 2:20 PM Mason Freed <[email protected]> wrote: > >> >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDg6ZHCp6Ty%2BOAJab8cC94aXK8k5z6yq7sq2eFvj_8S5xw%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/CAOMQ%2Bw_-EbcQjj4T%2Beoe_NybqSKHeaLSHc4bNA2bTsB3ZH-gqg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_-EbcQjj4T%2Beoe_NybqSKHeaLSHc4bNA2bTsB3ZH-gqg%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/CAL5BFfV7TG3GzQgYu62vKObnWnDsMwiKMXpc8ZwgnY3j-rwJWQ%40mail.gmail.com.
