Web Compatibility #187
Comments
|
Note that this is not yet a complete set of bugs / tests and I expect more to be added before the start of the selection period. |
|
What's the status of #27? Does that make sense to include at this point? |
|
@karlcow , what approach did you use to generate the list of bugs in #187 (comment)? |
|
@progers So exactly what I said in the previous comment
starting with the Interop List of Bugs opened on the Chromium project and checking which one mentioned the other browsers and selecting those where Firefox and Safari implementations were aligned. This is far to be perfect and the list could be a lot longer. The why is maybe more interesting. Webcompat issues are often created by the de facto implementation of the dominant market share browser. Both WebKit and Gecko teams can testify about this, where a bug is reported for a site breaking in Firefox or Safari, while they have the correct behavior, but the web developer assumed that the correct was Chrome's one, because the webdev worked exclusively with Chrome. The result is that other browsers have to implement quirks, site interventions or worse change the spec to align on chrome behavior. So by fixing these paper cuts (if they are real bugs on Chrome side) would make it possible to avoid webcompat pressures on other engines and avoid confusion for web developers. I hope it helps. |
|
I think the above approach can likely be improved upon. Bugs are marked "interop" in the chromium bug tracking in a somewhat haphazard fashion. E.g. the above list includes bugs filed by chromium engineers noting a difference - but no evidence this affects a real world site (bugs filed by web developers have a higher probability however). Examples of the specific issue being a repeat issue (e.g. references from the webcompat.com project) would be helpful to indicate that the bug is an issue (the overlay example is great for example). |
|
Regarding crbug.com/1293302 specifically - we believe (from my understanding of the issue) is that the Blink behaviour is correct - and there are existing WPTs which are partially covering the issue (however they could be expanded): I'll double check with Ethan - but we'll likely WontFix this specific issue. |
|
From a gecko point of view "bug which got filed on blink but where the blink behaviour is now / was always correct" isn't a reason to remove the bug; it's a reason to ensure that it's fixed in gecko instead (it could, for example, be a case where we're operating on outdated assumptions about the correct behaviour). Of course it's even higher priority if we have evidence of widespread usage of the relevant feature, or active breakage. In this specific case I think the relevant gecko bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1530097, which is indeed associated with a number of cases of breakage. |
|
@jgraham what's your plan for this currently being "not yet a complete set of bugs"? how are we coming up with the list of compat bugs here? |
|
@jgraham - This is why we'd like to expand the grid/flex areas for 2023. A (very) quick look through Gecko's bugs reveals the following issues: Ian |
|
I will audit the proposed bugs, and which have wpt tests. In at least some cases there are ad-hoc tests and it would be reasonably easy to port them to wpt if that hasn't already happened. For the grid and flex bugs (and similar cases), if there's a gecko bug and it has any webcompat links in the see-also, or has a webompat priority set I think it makes sense to include in this cateogry. And if there's other parts of the feature with browser-specific failures that also implies at least a compat hazard so I'm also broadly in favour of including those. |
|
Also, @karlcow I'm not sure if there are failing WPT tests representing each of the issues you listed. Do you know? |
|
So an updated list of proposed bugs, some of which still need to have testcases exported to wpt:
I've tried to look at all the suggestions for ones that are clearly causing real-world compat issues. @karlcow might have additional evidence of compat issues from the Chromium bugs (or indeed from WebKit bugs). In terms of the general grid/flex/etc. carryover issues, I think it's unfortunate that we haven't had a clear plan for those before now. My ideal solution would have been to have specific proposals for each carry over, so they could be assessed along with other priorities, and then maybe merged into the compat bucket where appropriate. But we didn't have a clear process for that in time. The list above only includes the issues for which I could easily find compat problems. But I think we should have an additional discussion about how to handle carry-over in general. |
This seems like the wrong bug? https://bugs.chromium.org/p/chromium/issues/detail?id=1271942 and https://bugs.chromium.org/p/chromium/issues/detail?id=554361 (oh, maybe you lost the last digit?) seem more relevant. And to note, the WebKit behaviour today is that it is a synonym of auto. |
|
I will look for more details. But what would be good to do probably for all of us is to have a list for 2024. Longterm Webcompat bugs have a nasty side effect as they can't be demonstrated or showed easily because 1. browsers change the standard behavior to avoid them, 2. implement quirks or 3. webdevs adjust their codepath with UA sniffing for sending different behaviors. |
In Igalia we're starting to look into this issue, and we'll be fixing it at some point in the next year. The issue should probably be limited to the fact that Chromium counts an element boundary before a space as a line breaking opportunity, and you can reproduce this in a test case that doesn't require zoom. The fact that different zoom levels result in different line breaks even when the line width does not depend on the viewport size is a separate issue that should not count for Interop 2023. However, as we were initially looking into this bug, we noticed that Webkit does seem to have this bug in some cases, although maybe not in all of the cases where Chromium has it, or it might have a separate but related bug. So should it still count for Interop 2023? Edit: I had tested this bug in Webkit using Epiphany (Gnome Web), and apparently Safari doesn't have it. |
|
@jgraham for decoration box semantics
https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10982
|
I'm reviewing my own suggestions and I think we can remove a bunch of them. PROBABLY
MAYBE
For @jgraham list, still reviewing them, but:
To be continued. |
I think it's acceptable if the outcome is that we standardise the Blink/WebKit behaviour and Firefox adopts that (although obviously that's not my preferred outcome). https://github.com/webcompat/knowledge-base/blob/main/data/overflow-overlay.yml has links to a lot of examples of this causing breakage in the wild. https://bugs.chromium.org/p/chromium/issues/detail?id=811172 is another Blink/WebKit bug that has caused a number of compat problems. |
|
So what is this proposal at this point? Is it just @jgraham's list of proposed bugs in #187 (comment), or is it a broader union of the listed bugs here? |
|
I'm commenting on proposals for features that came up in State of CSS 2022 going by the list in #248. Obviously this focus area cannot be named directly, but it is notable that flexbox is still top of mind. A lot of that is due to flex gap not being available in older browser versions still in use, but also comments like "Flexbox seems to have some overflow bugs still. (min-width: 0; fix, anyone?)"
|
|
@gsnedders I'm treating this proposal as tracking the union of @jgraham's issues and the ones from @karlcow. |
|
Is this still on the table, given the discussion in w3c/csswg-drafts#8031? After internal review of the tests, this is one we're not sure about including. |
|
That's not in @karlcow's reduced list #187 (comment) so I consider it already removed. But in any case, removing it isn't a problem. |
|
Can all the testcases be exported to WPT? Makes it easier to assess the proposals generally. |
|
Per request we can also consider the |
Yes, but realistically I doubt we can do that by Thursday. If there are concerns with specific tests once they're ported to wpt I think it would be possible to deal with that later. |
|
@jgraham Should we add https://bugzilla.mozilla.org/show_bug.cgi?id=1772305 to the webcompat focus area. It creates this compat issue for Safari while doing the right thing. |
|
Tests update for the areas I suggested:
Move to flex/grid:
|
|
Still need to identify / add tests from #187 (comment) and https://bugzilla.mozilla.org/show_bug.cgi?id=1772305 (cc @karlcow) |
|
What about issues mentioned in #187 (comment) ? |
|
@bfgeek I thought those tests were being added to grid / flexbox focus areas. I agree they're important and shouldn't be lost. |
Should:
Also be dropped from this particular area as they are already in the grid/flexbox focus areas? |
|
(Just after consistency about how we think of these) |
I'm currently looking into fixing this in Blink, and working on a more comprehensive WPT test. Note that the Chromium bug isn't just about Also, I don't think https://wpt.fyi/results/css/CSS2/text/text-align-white-space-003.xht is related to this issue at all, since this is about whether
|
|
@andreubotella how soon do you expect to have tests in wpt? If not in the next coupld of weeks, could we start by merging and tagging the test I ported and then replacing it once your tests are landed? |
|
@bfgeek I don't mind moving those into flexbox/grid tests instead of here. |
|
I already opened a PR: web-platform-tests/wpt#37985 |
|
I know it might be too late, but I'll post this combat issue here and leave it up to you to decide if it can be included in interop 2023 or not. There are some interop issues on The spec includes punctuation and whitespace before and after the initial letter, as defined in css-pseudo-4. Browsers are not interoperable and supports punctuation and whitespace to a varying degree: Safari: Chrome: Firefox: There is a crude test in WPT. It currently fails for all browsers: There are open issues in all browsers here: |
Unfortunately the proposal period for Interop 2023 is indeed over. You are of course welcome (and encouraged!) to propose |
|
Thank you for proposing Web Compatibility for inclusion in Interop 2023. We are pleased to let you know that this proposal was accepted as the Web Compat 2023 focus area. You can follow the progress of this Focus Area on the Interop 2023 dashboard. For an overview of our process, see the proposal selection summary. Thank you for contributing to Interop 2023! Posted on behalf of the Interop team. |
Description
A focus area for small bugs that cause known site compatibility issues, or documented problems for authors creating libraries or sites, but which are not part of a larger feature that's appropriate for its own focus area.
Rationale
Observed compatibility bugs which cause breakage for users are often not missing features, but specific cases where existing browsers don't follow the spec for features that are implemented. On their own these would be hard to fit into the Interop process since a focus area for a single bug, however important, is hard to weigh as part of the metric. However having a single focus area for these issues seems to have worked well in 2022, with browsers going from ~20% to ~100%, and fixing several bugs that were known to cause problems for users, but had not previously got priority.
Specification
All included bugs will have a specification (although in some cases it may be that "success" is changing the specification, testcase, and "conforming" implementations to match what's actually required by compat).
Inclusions will be motivated by observed compat issues (e.g. in webcompat.com or author-reported issues that they've had to work around when developing libraries.
Tests
Since this is a somewhat miscellaneous selection of bugs, it's anticipated that tests may be added from other focus areas where the overall focus area doesn't get priority but there are a small number of observed pain points which do get priority. During the selection process participants can request removal of any tests that would cause them to object to the proposal.
Suggested bugs / rationale (tests to be added):
The text was updated successfully, but these errors were encountered: