-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
ARIA WG Agenda+ new namefrom: heading tests for accname #44490
ARIA WG Agenda+ new namefrom: heading tests for accname #44490
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't think that some of these could get their name from content. Or, are you trying to say they should be able to?
For reference, I'm looking at the list here: https://w3c.github.io/aria/#namefromcontent
commenting to reference the rest of my feedback I gave on this over in another thread, as my comment contains markup patterns that might be worth adding to this wpt |
Test PR will need to be changed since the AccName spec PR algo will be changed from IDDFS to DFS, pending implementor approval. |
@MelSumner please ignore the re-requested review. I was trying to clear your approval since this PR needs more work and that big green "squash & merge" button is so tempting. I'll convert to a draft PR instead. |
Selector matches any ::scroll-button, recently added to spec. Bug: 388538943 Change-Id: I5253f369ee1a6a5351f8064f4e238dfbf50a87dc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6185896 Commit-Queue: Rune Lillesveen <[email protected]> Reviewed-by: Daniil Sakhapov <[email protected]> Cr-Commit-Position: refs/heads/main@{#1409581}
Change-Id: I77e64198df9a3f117b2007709f922a364940e92c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6188820 Commit-Queue: Rune Lillesveen <[email protected]> Reviewed-by: Daniil Sakhapov <[email protected]> Cr-Commit-Position: refs/heads/main@{#1409591}
Offscreen canvas was not inheriting the direction attribute in the way the spec described (which I am in the process of reworking). When the direction is inherit the offscreen should try to get it from a canvas element it is associated with, or the document if there is no associated element (i.e. it was not transferred). Also add tests for canvas text direction = "inherit" Bug: 390272618 Change-Id: I5f862a4e2337b94b2eaa721733725a860872a824 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6173291 Reviewed-by: Andres Ricardo Perez <[email protected]> Commit-Queue: Stephen Chenney <[email protected]> Cr-Commit-Position: refs/heads/main@{#1409617}
The spec is currently a work-in-progress[1] but this comment[2] describes the API. [1] w3c/csswg-drafts#10128 [2] w3c/csswg-drafts#8942 (comment) Bug: 390314945 Change-Id: I6ac50730653e70219775895c315f91f771ea7c13 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6182723 Commit-Queue: David Awogbemila <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Cr-Commit-Position: refs/heads/main@{#1409620}
Before-change style should inherit from parent after-change style for @starting-style. That means we need to cascade after-change separately also for before-change style in this case. This CL separates out ensuring of after-change style so that it can be shared between before- and after-change style computations. Also, the StyleRecalcContext must be set up correctly with old_style to ensure that: 1. @starting-style rules are not applied for after-change style. 2. @starting-style rules are applied for before-change style when @starting-style is the before-change for a given style resolution. Bug: 40337057 Change-Id: I92af1934fbab45bb294ea92055ec3be373a8caa5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6185041 Reviewed-by: Anders Hartvoll Ruud <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1409627}
Bug: 40337057 Change-Id: I3ea0283d2ca9ff4730696afa06a9cc82ddab700e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6175093 Reviewed-by: Anders Hartvoll Ruud <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1409648}
BUG=chromium:387077342 Change-Id: I3289327d21e22a6c42edb56d3a9699a0a7cf8d06 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6186273 Reviewed-by: Harald Alvestrand <[email protected]> Reviewed-by: Henrik Boström <[email protected]> Commit-Queue: Philipp Hancke <[email protected]> Cr-Commit-Position: refs/heads/main@{#1409660}
Implements the sourceLanguage and targetLanguage attributes. Bug: 391439683 Change-Id: I7dde1a78de30ad959ca92ee424596fb7442786b9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6186019 Commit-Queue: Nathan Memmott <[email protected]> Reviewed-by: Ming-Ying Chung <[email protected]> Cr-Commit-Position: refs/heads/main@{#1409688}
Change-Id: Ic65307069147f6325303fc35dfda29f733df6346 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6180162 Commit-Queue: Russ Hamilton <[email protected]> Reviewed-by: Qingxin Wu <[email protected]> Cr-Commit-Position: refs/heads/main@{#1409702}
Android content-URIs typically are not related to the display name, so we must keep the display name to use it for mime guessing for File.type. Bug: 393513313 Change-Id: I811cf81d9e17402a401190f67604addf094dbed0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6228436 Commit-Queue: Joel Hockey <[email protected]> Reviewed-by: Fergal Daly <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415390}
…ists. Differential Revision: https://phabricator.services.mozilla.com/D235205 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1942695 gecko-commit: bc9e2229b06cc721840598cbf4f7d1908928fa58 gecko-reviewers: firefox-style-system-reviewers, emilio
Try a bit harder to set the window size and position. The change to set_get_window_rect.html is justified as follows: * The Window Position test already fails on Linux (actually only on Mutter, because of what I think is a bug... We request the right move to (150, 175), but the compositor moves us to (150, 137). My patch doesn't change that. * However the second test (window size) relies on the position test to have moved the window to the right place, as it hard-codes the old window position. On the second request, Mutter actually does the right thing and moves us there. Instead, make sure not to trigger a move in the window size test. * Use a slightly bigger size on the fractional sizes test, because otherwise it hits the minimum window with on wayland (where the outer size includes a somewhat large shadow). * Also include the minimum screen size as well: The set.py change fails locally, but not on automation, without that change, but it is correct afaict. * Some tests in set.py fail on automation still, but not locally. These are very likely mutter issues / bugs: The browser is not really required to honor our maximize / size requests as-is... I can't repro these locally at all even with virtually the same screen configuration as automation, so I suspect these have been fixed upstream already. Differential Revision: https://phabricator.services.mozilla.com/D234902 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=581863 gecko-commit: fc49e83f5b434d7d0b866a1712fd52a9f5f05b39 gecko-reviewers: whimboo, webdriver-reviewers
…ests#50455) * [WebDriver BiDi] Add test for providing both contexts * remove wrong test
Bug: 40268059 Change-Id: I8c9e541e6d12fe91f8e188339e4bdb7e1bbfdf75 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6226040 Commit-Queue: Philip Jägenstedt <[email protected]> Reviewed-by: Philip Jägenstedt <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415428}
This is now fairly easy to do by extending the CycleElem type introduced in CL:6176920. Both attributes (used by attr()) and locals need the AtomicString type; we can distinguish between the two cases using a StrongAlias. Note that this CL follows the behavior described in Issue 11500, not what the spec currently says. Therefore, the test is marked as tentative. w3c/csswg-drafts#11500 Bug: 325504770 Change-Id: I5a00e03175f0446a0ec6e6ba771253b4ea5f48e6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6190327 Commit-Queue: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Munira Tursunova <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415484}
* [wdspec] event helper * add timeout config * remove async poll
In other words, when substituting an attribute like "var(--x)", the referenced "--x" must respect the local context: it can either refer to a local variable, and argument, or a custom property. https://drafts.csswg.org/css-mixins-1/#locally-substitute-a-var Bug: 325504770 Change-Id: I68a1d4cecc173ebe17692087edaa1014eab27466 Fixed: 391570175 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6190814 Reviewed-by: Munira Tursunova <[email protected]> Commit-Queue: Anders Hartvoll Ruud <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415486}
…ecessary. In the case of position:fixed frame, walking up the frame tree doesn't reach to the root scroll container, thus we need to invoke ScrollToVisual outside the walking up the tree loop. This commit has two independent tests, a web platform test and a mochitest. Unfortunately the web platform test doesn't work on Firefox, since WebDriver (GeckoDriver) doesn't support touch action yet. It works on Chrome. What the mochitest does is mostly equivalent with the web platform test, but with nsIDOMWindowUtils.setResolutionAndScaleTo and zoomToFocusedInput. Differential Revision: https://phabricator.services.mozilla.com/D236061 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1943865 gecko-commit: 2249a06891096a52bef8c581f2181d933f21b4b3 gecko-reviewers: dlrobertson
As natural size for HTMLImageElement.naturalWidth/Height[1] (also .width/height) and HTMLInputElement.width/height[2] we were computing the concrete object size resolved using a default object size of 300x150. We should now just return the actual natural width and height. This will affect cases where a natural width/height is not specified (yielding zero instead of whatever value the concrete object size algorithm produces). Guarded by runtime enabled feature: HTMLImageElementActualNaturalSize Set to "test" for now to collect some data from the use counter. Any resulting difference in the returned value is counted by the HTMLImageElementNaturalSizeDiffersForSvgImage use counter. [1] https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-naturalwidth [2] https://html.spec.whatwg.org/multipage/input.html#dom-input-width Bug: 41357911 Change-Id: I158f5f373eee19c6ad586cf31ea1f0ac5d865205 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6084998 Reviewed-by: Noam Rosenthal <[email protected]> Commit-Queue: Fredrik Söderquist <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415496}
Signed-off-by: Xiaocheng Hu <[email protected]>
This tracks development of the spec: WICG/sanitizer-api#254 The PR makes the default for "comments:" and "dataAttributes:" keys in the configuration depend on whether this is for safe or unsafe use. That requires a bit of plumbing, since now the logic to interpret a config depends on a new flag. Also adds test cases. Bug: 356601280 Change-Id: I076c5418006b0dc35babbffd7d991e04c0f1d522 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6189121 Commit-Queue: Daniel Vogelheim <[email protected]> Reviewed-by: Yifan Luo <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415510}
Some of the canvas properties that are part of CanvasTextDrawingStyles (https://html.spec.whatwg.org/#canvastextdrawingstyles) had been modified to use enums defined from the IDL definition of the rendering context (fontStretch and textRendering). This CL creates enums for the rest of the CanvasTextDrawingStyles properties. Getters and setters had to be modified, as well as a unit test. Generated tests for setting and getting this properties already exist in WPT, as defined in text.yaml. Bug: 341213359 Change-Id: Ic8c30219a039c96cfd83dd078157d9fb60565e03 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6000733 Commit-Queue: Andres Ricardo Perez <[email protected]> Reviewed-by: Koji Ishii <[email protected]> Reviewed-by: Jean-Philippe Gravel <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415577}
This reverts commit 4ee07bfc313ed29c3575eb563b28228c56468b2d. Reason for revert: We no longer believe that this behavior is a good idea. Bug: 394119730 Original change's description: > Include <img> alt text in <option> labels > > Discussion: whatwg/html#10317 > Change-Id: Ie6ed230eb75d3ec24c51c76d587a11dde3d44b5a > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6137091 > Reviewed-by: David Baron <[email protected]> > Commit-Queue: Joey Arhar <[email protected]> > Cr-Commit-Position: refs/heads/main@{#1404536} Change-Id: Iad0757df430a9e1beab68aa36e71c6f4f782fe79 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6227955 Reviewed-by: David Baron <[email protected]> Commit-Queue: Joey Arhar <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415623}
The predicate would allow all <color> values to be cached. With the extended syntax for <color> this is a bit too simplistic. Change the predicate to be a bit more conservative by only allowing known absolute <color>s to be cached. Fixed: 393879744 Change-Id: Iad4498b4baf6a1504b0b225b2afcb2e5ac4f48a4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6229917 Auto-Submit: Fredrik Söderquist <[email protected]> Reviewed-by: Rune Lillesveen <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415631}
This CL introduces parsing for the `row-rule-break` property which controls the behavior of breaking gap decorations within gaps into segments, see: https://drafts.csswg.org/css-gaps-1/#break. Bug: 357648037 Change-Id: I5b40caa660bcdee91d9e6718e270a965bd1dd16c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6217445 Reviewed-by: Kurt Catti-Schmidt <[email protected]> Reviewed-by: Alison Maher <[email protected]> Reviewed-by: Kevin Babbitt <[email protected]> Commit-Queue: Sam Davis Omekara <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415655}
In the canvas WPT test generator, test parameters can refer to each other. The `code` parameter for instance can have a Jinja tag referring to another parameter (`{{ expected_color }}` for instance), and that parameter can in turn have Jinja tags referring to other parameters, and so on. This was implemented by repetitively rendering Jinja templates, until the output of a render pass produces the same results as the input. At each render pass, parameters would be expanded into the template, and if that expansion happens to add new Jinja tags, these will be rendered in the following render pass. This was inefficient since it required every templates to be rendered one extra time. This was also fragile and a maintenance burden since we had to treat some test parameters as special case that need to be rendered before they can be used. For instance, 'name' or 'desc' could contain Jinja tags, so we had to pre-render these, just in case. For performance reasons, we would not do this systematically to all parameters though, breaking symmetry in feature support. More importantly though, the multi-render-pass strategy prevented the use of Jinja macros. For instance: code: | {% macro format_color(color) %} {{- '%d,%d,%d,%d' | format(...) -}} {% endmacro %} @Assert pixel 50,25 == {{ format_color(expected_color) }}; expected_color: | {% macro calculate_color(...) %} ... {% endmacro %} {{ calculate_color(...) }} With the multi-render-pass strategy, the `format_color` macro would be evaluated on the first render pass, but it would operate on the Jinja template source code in `expected_color`. It really would need to operate on the rendered result of that child template. All of the above can be addressed by using an alternative parameter chaining strategy. This CL adds a new `_LazyRenderedStr` type, which is an `str` that holds a template, but evaluates to the rendering result of that template when read. By using this type in the Jinja parameter dictionary, we are automatically rendering parameters when they used by Jinja. Thus, parameters automatically get rendered in the right order. In the example above, Jinja would render `code`, encounter the parameter `expected_color`, which would get rendered here and then, returning that rendering result as `expected_color` value to be used in the `code` template. Bug: 40207206 Change-Id: I12a9861ae7d94340c4858b34057eb0144a7da67f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6203781 Reviewed-by: Andres Ricardo Perez <[email protected]> Commit-Queue: Jean-Philippe Gravel <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415686}
This reverts commit 781da34c8809a01d0502816cd83b4593ddad4751. Reason for revert: Caused Stability issues b/394278536 and b/394270222 Original change's description: > [Editing] Resolve styles during serialization > > Resolving styles as part of serialization when generating html on copy > of a selection. This ensures css vars present in CSSPropertyValue set > are calculated. > > Bug: 383465164 > Change-Id: I870cb3c6b43c77700db11753577be5fcc8062466 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6197780 > Reviewed-by: Kent Tamura <[email protected]> > Reviewed-by: Siye Liu <[email protected]> > Commit-Queue: Rakesh Goulikar <[email protected]> > Cr-Commit-Position: refs/heads/main@{#1414908} Bug: 383465164 ,394278536, 394270222 Change-Id: I05e86b656e6296677a4205438a1e3fc35ce2026c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6230321 Bot-Commit: Rubber Stamper <[email protected]> Owners-Override: Prudhvikumar Bommana <[email protected]> Commit-Queue: Prudhvikumar Bommana <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415735}
This reverts commit 66ceeef1ee9be8a1da3899f6d7df6045689fbe2a. Reason for revert: LUCI Bisection has identified this change as the culprit of a build failure. See comment in the original CL. Original change's description: > Use IDL enums for all CanvasTextDrawingStyles in Canvas2D > > Some of the canvas properties that are part of CanvasTextDrawingStyles > (https://html.spec.whatwg.org/#canvastextdrawingstyles) had been > modified to use enums defined from the IDL definition of the rendering > context (fontStretch and textRendering). > > This CL creates enums for the rest of the CanvasTextDrawingStyles > properties. Getters and setters had to be modified, as well as a unit > test. Generated tests for setting and getting this properties already > exist in WPT, as defined in text.yaml. > > Bug: 341213359 > Change-Id: Ic8c30219a039c96cfd83dd078157d9fb60565e03 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6000733 > Commit-Queue: Andres Ricardo Perez <[email protected]> > Reviewed-by: Koji Ishii <[email protected]> > Reviewed-by: Jean-Philippe Gravel <[email protected]> > Cr-Commit-Position: refs/heads/main@{#1415577} Bug: 341213359 Change-Id: I7038cb4140c23d014bda22e5969d798d45a038e1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6226570 Commit-Queue: Andres Ricardo Perez <[email protected]> Bot-Commit: Rubber Stamper <[email protected]> Reviewed-by: Jean-Philippe Gravel <[email protected]> Reviewed-by: Fernando Serboncini <[email protected]> Auto-Submit: Andres Ricardo Perez <[email protected]> Commit-Queue: Fernando Serboncini <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415729}
Scroll usually snaps to the nearest pixel. The main thread scroll offset should be rounded as well to ensure consistency with compositor scrolls Bug: 394306944 Change-Id: I9a6893c44157f9b743defeba632d573ca1459425 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6226305 Commit-Queue: Robert Flack <[email protected]> Reviewed-by: Vladimir Levin <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415740}
This set of IndexedDB WPTs currently only run in a window environment. This change extends them to also run in dedicated, shared, and service worker environments. Bug: 41455766 Change-Id: I8e984b4fb51293d70659e657c449f2dfb9697610 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6220542 Reviewed-by: Steve Becker <[email protected]> Commit-Queue: Rahul Singh <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415813}
…sitions When we scroll to snap positions we scroll to a rounded location. This CL ensures that the disabled state determination applies the same rounding logic. Bug: 393100295 Change-Id: I1fbcfb62ef7514d31c85e02a7980279f36363a42 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6221875 Commit-Queue: Robert Flack <[email protected]> Reviewed-by: Vladimir Levin <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415825}
This set of IndexedDB WPTs currently only run in a window environment. This change extends them to also run in dedicated, shared, and service worker environments. Bug: 41455766 Change-Id: Ie80945a754dd614c38cf1bdbc41b24efd2053116 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6220616 Reviewed-by: Steve Becker <[email protected]> Commit-Queue: Rahul Singh <[email protected]> Cr-Commit-Position: refs/heads/main@{#1415869}
Does anyone ever want that? Declaring bankruptcy on this old PR and starting fresh. |
Abandoned PR. Formerly related to web-platform-tests/interop-accessibility#47
Need feedback on this one from the ARIA WG and implementors due to the initial proposal of "iterative deepening depth first search" (IDDFS). It will likely perform better, but some authors might expect a standard (but much slower) depth first search (DFS).