On Tue, Dec 3, 2024 at 9:31 PM Stephen Chenney <schen...@chromium.org> wrote:
> > > On Tue, Dec 3, 2024 at 8:13 PM Vladimir Levin <vmp...@chromium.org> wrote: > >> >> >> On Tue, Dec 3, 2024 at 10:34 AM Stephen Chenney <schen...@chromium.org> >> wrote: >> >>> >>> >>> On Mon, Dec 2, 2024 at 11:38 AM Andrew Paseltiner < >>> apaselti...@chromium.org> wrote: >>> >>>> On Thu, Nov 21, 2024 at 9:50 PM Domenic Denicola <dome...@chromium.org> >>>> wrote: >>>> >>>>> With my HTML editor hat on, I support keeping parity between <a> and >>>>> <area>. Although <area> is used much less, we try to keep them symmetric >>>>> whenever possible. >>>>> >>>> Sounds to me like we should go ahead with this for parity. >>>> >>>>> >>>>> On Fri, Nov 22, 2024 at 5:19 AM Mike Taylor <miketa...@chromium.org> >>>>> wrote: >>>>> >>>>>> On 11/21/24 1:37 PM, Andrew Paseltiner wrote: >>>>>> >>>>>> On Thu, Nov 21, 2024 at 1:26 PM Mike Taylor <miketa...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> On 11/21/24 12:49 PM, Chromestatus wrote: >>>>>>> >>>>>>> Contact emails apaselti...@chromium.org >>>>>>> >>>>>>> Explainer >>>>>>> https://github.com/WICG/attribution-reporting-api/blob/main/EVENT.md#registering-attribution-sources >>>>>>> >>>>>>> Specification >>>>>>> https://wicg.github.io/attribution-reporting-api/#html-monkeypatches >>>>>>> >>>>>>> Summary >>>>>>> >>>>>>> For Attribution Reporting, the attributionsrc attribute was already >>>>>>> unintentionally processed on <area> elements due to code shared with >>>>>>> <a>, >>>>>>> which intentionally supported that attribute. For completeness, we >>>>>>> expose >>>>>>> the attribute on <area> with identical syntax and semantics to <a> and >>>>>>> without changing the previous processing: When an <area> tag with an >>>>>>> attributionsrc attribute is navigated, the foreground request may >>>>>>> register >>>>>>> navigation sources and, if the attribute is non-empty, one or more >>>>>>> background requests will likewise be able to register navigation >>>>>>> sources. >>>>>>> >>>>>>> Is this something developers actually want, i.e. are imagemaps a use >>>>>>> case advertisers are asking to be supported? If not, why not just fix >>>>>>> what >>>>>>> seems to be a bug? >>>>>>> >>>>>> It's true that we haven't specifically heard from developers that >>>>>> they want this, but we also don't have any data about whether the >>>>>> existing >>>>>> behavior is being relied on, and I'm not clear on the prevalence of image >>>>>> maps for the relevant use cases in general. Is there existing precedent >>>>>> for >>>>>> supporting a navigation-related feature on <a> but not <area>? >>>>>> >>>>>> I don't have the answer to that - perhaps someone else will know. >>>>>> >>>>>> >>>>>> Given that we support this on multiple other navigation surfaces >>>>>> (<a>, window.open, and context-menu on <a>), and that the fix is >>>>>> quite simple >>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/6022268>, >>>>>> I'd err on the side of not breaking anyone, but we could also try to >>>>>> gather >>>>>> usage data first. >>>>>> >>>>>> Yes, agree - we should take a look at usage/potential breakage here. >>>>>> Have you tried to look at HTTPArchive? This feature has shipped long >>>>>> enough >>>>>> that there should be something there (if anything exists at all). Or >>>>>> there's the regular UMA route, but that's slower. >>>>>> >>>>> It would surprise me if this data showed up in HTTPArchive -- the >>>> majority of attributionsrc uses will be in dynamically injected DOM >>>> elements. >>>> >>>> We could try to go with UMA, but it may not be worth the effort. >>>> >>> >>> After recent breakage (caused by me) there's a desire to add UseCounter >>> or other lightweight UMA tracking before changing web-facing behavior, >>> particularly when there is otherwise no real way of knowing if anyone is >>> relying on it. The lack of developer signals increases the risk, as does >>> the very long time the existing behavior has been in place. >>> >>> I do strongly agree that the feature is worth doing. >>> >>> Stephen. >>> >> >> I'm not sure I understand what we would be measuring? As I understand it, >> this intent is to expose attributionsrc on <area> where previously it >> wasn't exposed, although it was already processed. It doesn't sound any >> different from typical "new feature" intents, in that we don't usually >> check if names, for example, conflict with existing code. If anything, this >> seems even safer in that the actual behavior wouldn't change (due to a >> current Chromium bug). >> >> Thanks, >> Vlad >> > > I made the comment about getting usage data because the conversation so > far seems to be indicating some chance of breakage. > > I guess to get breaking behavior you would need to be trying to set > element.attributeSrc in JS on an <area> element and having it fail now, > while it would start to work once this change is made. Is that right? > > In which case I don't think there is any way to measure that ahead of > time. It's also hard to see how a site would depend on the call failing. > But you could add a use counter to the CL and see if there is any immediate > usage at all, as anything other than near-zero initial usage suggests the > JS code was already in place somewhere. > > Or is there some other path to breakage? > We can add a usage counter, but I'm not clear on how this change could cause any breakage: Even setting element.attributionSrc in JS today on an <area> element wouldn't throw an exception or otherwise break; it would just create a new property on the element that does nothing. > > Stephen. > > >> >>> >>>> Blink component Blink >>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> >>>>>>> >>>>>>> TAG review Covered by existing Attribution Reporting I2S as this is >>>>>>> a small change re-using the existing API surface. >>>>>>> >>>>>>> TAG review status Not applicable >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> *Gecko*: No signal >>>>>>> >>>>>>> *WebKit*: No signal >>>>>>> >>>>>>> *Web developers*: No signals >>>>>>> >>>>>>> *Other signals*: >>>>>>> >>>>>>> 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? >>>>>>> >>>>>>> No. >>>>>>> >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? Yes >>>>>>> >>>>>>> Is this feature fully tested by web-platform-tests >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>> ? Yes >>>>>>> >>>>>>> Flag name on about://flags None >>>>>>> >>>>>>> Finch feature name None >>>>>>> >>>>>>> Non-finch justification >>>>>>> >>>>>>> This is a minor change largely reusing existing code and behavior. >>>>>>> The only web-exposed detail here is the addition of an already-processed >>>>>>> HTML attribute to the corresponding tag's IDL definition. >>>>>>> >>>>>>> >>>>>>> Requires code in //chrome? False >>>>>>> >>>>>>> Tracking bug https://issues.chromium.org/379275911 >>>>>>> >>>>>>> Measurement n/a >>>>>>> >>>>>>> Availability expectation Covered by existing Attribution Reporting >>>>>>> I2S as this is a small change re-using the existing API surface >>>>>>> >>>>>>> Adoption expectation Covered by existing Attribution Reporting I2S >>>>>>> as this is a small change re-using the existing API surface >>>>>>> >>>>>>> Adoption plan n/a >>>>>>> >>>>>>> Non-OSS dependencies >>>>>>> >>>>>>> Does the feature depend on any code or APIs outside the Chromium >>>>>>> open source repository and its open-source dependencies to function? >>>>>>> No. >>>>>>> >>>>>>> Estimated milestones >>>>>>> Shipping on desktop 133 >>>>>>> Shipping on Android 133 >>>>>>> Shipping on WebView 133 >>>>>>> >>>>>>> Anticipated spec changes >>>>>>> >>>>>>> Open questions about a feature may be a source of future web compat >>>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>>> issues in the project for the feature specification) whose resolution >>>>>>> may >>>>>>> introduce web compat/interop risk (e.g., changing to naming or >>>>>>> structure of >>>>>>> the API in a non-backward-compatible way). >>>>>>> n/a >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> https://chromestatus.com/feature/6547509428879360?gate=6545976813420544 >>>>>>> >>>>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>>>> To view this discussion visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/673f72a6.2b0a0220.3bb1d2.02f2.GAE%40google.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/673f72a6.2b0a0220.3bb1d2.02f2.GAE%40google.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 blink-dev+unsubscr...@chromium.org. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5f406b3c-98f1-4f62-94e9-43e61bba4556%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5f406b3c-98f1-4f62-94e9-43e61bba4556%40chromium.org?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 blink-dev+unsubscr...@chromium.org. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP6jJUgkRFLr%3DP5FumrCoOh1bFembn6FqASLcm4BtZ5Vg4b7rw%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP6jJUgkRFLr%3DP5FumrCoOh1bFembn6FqASLcm4BtZ5Vg4b7rw%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 blink-dev+unsubscr...@chromium.org. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQispi5Y8N7oWLjhS26U5p3TRs7HbZXcfjGyQg17Mgkfw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGsbWzQispi5Y8N7oWLjhS26U5p3TRs7HbZXcfjGyQg17Mgkfw%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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP6jJUhuAYmCTDQXSNmC9uH4KGYeuN9DnMyYWTiQiRsFsnh1Zg%40mail.gmail.com.
