[webkit-dev] Removing old HarfBuzz backend?
Hi, Bug https://bugs.webkit.org/show_bug.cgi?id=108077 was filed to track discuss removing the old HarfBuzz backend code. From an earlier bug thread it seemed that no port has a dependency on this code any more. I am proposing patch to remove it. If there's any concerns and your port didn't move to harfbuzz-ng yet, please let me know. Dominik -- Dominik Röttsches Intel Finland Oy - BIC 0357606-4 - PL 281, 00181 Helsinki ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes to the WebKit2 development process
IMHO, recently, contributors as well as WK2 owners are a bit suffering from it. I think we can go to a better direction: making all developers happy as well as resolving WK2 owners' concerns. I think the straightforward way to achieve this is to let somebody be an owner from every port. He/she should could be restricted to approve only platform specific changes. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes to the WebKit2 development process
El mar, 29-01-2013 a las 09:39 +0100, Balazs Kelemen escribió: IMHO, recently, contributors as well as WK2 owners are a bit suffering from it. I think we can go to a better direction: making all developers happy as well as resolving WK2 owners' concerns. I think the straightforward way to achieve this is to let somebody be an owner from every port. He/she should could be restricted to approve only platform specific changes. And why not making it even simpler an allow any reviewer to r+ port-specific patches? If the patch doesn't change any cross-platform code at all there's no risk to break mac or any other port. Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=getsearch=0xF3D322D0EC4582C3 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes to the WebKit2 development process
Hi, Carlos Garcia Campos írta: El mar, 29-01-2013 a las 09:39 +0100, Balazs Kelemen escribió: IMHO, recently, contributors as well as WK2 owners are a bit suffering from it. I think we can go to a better direction: making all developers happy as well as resolving WK2 owners' concerns. I think the straightforward way to achieve this is to let somebody be an owner from every port. He/she should could be restricted to approve only platform specific changes. And why not making it even simpler an allow any reviewer to r+ port-specific patches? If the patch doesn't change any cross-platform code at all there's no risk to break mac or any other port. The answer is simple: Because Apple decided and proclaimed this fiat ... br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Enabling unprefixed CSS Transitions by default.
Hi, Last month I started working on supporting unprefixed CSS Transitions in WebKit. Today this work is guarded behind CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED enabled by default in trunk (but disabled in Chrome and probably release branches of other ports). After various patches we (Dean Jackson and myself) feel confident that the work on the transitions is ready for prime time. We still have bugs open in our bug tracker but that doesn't block the unprefixed version to go live. So the proposal is the following one : - Rename CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED to CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED to cover the future work for unprefixing the animations and the transforms (that I plan to focus after this). - Ship CSS Transitions unprefixed enabled by default with no feature flag to disable it. My proposal is tracked here : https://bugs.webkit.org/show_bug.cgi?id=108216 We can also be proud to say our implementation is maybe the most complete one (thanks to the various people involved). On a side note the usage of prefixed/unprefixed version is monitored through the FeatureObserver so we can later in the future have an idea of the usage and maybe remove the prefixed support. Thoughts? Patched landed : http://trac.webkit.org/changeset/141119 http://trac.webkit.org/changeset/140560 http://trac.webkit.org/changeset/140448 http://trac.webkit.org/changeset/140010 http://trac.webkit.org/changeset/139922 http://trac.webkit.org/changeset/139762 http://trac.webkit.org/changeset/139200 http://trac.webkit.org/changeset/139106 http://trac.webkit.org/changeset/139070 http://trac.webkit.org/changeset/138728 http://trac.webkit.org/changeset/138721 http://trac.webkit.org/changeset/138184 Thanks. -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Remove webkitDashArray attribute from CanvasRenderingContext2d
Hi WebKit folks, I would like to know if we can remove the following API's in the CanvasRenderingContext2d interface: webkitDashArray webkitLineDashOffset Both were implemented 16 months ago and replaced by the following standardized, unprefixed operations and attributes 5 months ago: setLineDash getLineDash lineDashOffset Note that the webkit prefixed attributes were just implemented in JavaScriptCore, no support for V8. Some of the main reason for supporting these attributes 16 months ago were: - Firefox supported them - PDF.js needed them for draw PDFs. PDF.js checks for the existence of the standardized operations and attributes now and uses them if supported. Would it be possible to clean up the code a bit more and remove the prefixed attributes? Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Breaking other ports
I understand that the new rules of the road for WebKit2 are that contributors are allowed to break non-Apple ports. However, those new norms do not extend to WebCore. In http://trac.webkit.org/changeset/138962, Alexey broke form resubmission confirmation in the Chromium port. In https://bugs.webkit.org/show_bug.cgi?id=108214, he is refusing to fix the regression. I don't view that as acceptable behavior from a member of the WebKit community. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove webkitDashArray attribute from CanvasRenderingContext2d
Our general approach to deprecating features is outlined on this wiki page: http://trac.webkit.org/wiki/DeprecatingFeatures It sounds like you're advocating the cold turkey approach here with a clear path forward for developers. Adam On Tue, Jan 29, 2013 at 5:46 PM, Dirk Schulze dschu...@adobe.com wrote: Hi WebKit folks, I would like to know if we can remove the following API's in the CanvasRenderingContext2d interface: webkitDashArray webkitLineDashOffset Both were implemented 16 months ago and replaced by the following standardized, unprefixed operations and attributes 5 months ago: setLineDash getLineDash lineDashOffset Note that the webkit prefixed attributes were just implemented in JavaScriptCore, no support for V8. Some of the main reason for supporting these attributes 16 months ago were: - Firefox supported them - PDF.js needed them for draw PDFs. PDF.js checks for the existence of the standardized operations and attributes now and uses them if supported. Would it be possible to clean up the code a bit more and remove the prefixed attributes? Greetings, Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove webkitDashArray attribute from CanvasRenderingContext2d
On 30/01/2013, at 12:46 PM, Dirk Schulze dschu...@adobe.com wrote: Would it be possible to clean up the code a bit more and remove the prefixed attributes? I don't think they should be removed yet. As you mentioned, it's been 16 months which is at least one Safari release cycle. I'd prefer that we give a console warning for now. Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling unprefixed CSS Transitions by default.
Related: when the unprefixed transitions are enabled by default, we plan to make a long-overdue blog post on Recent Updates to Transitions and Animations where recent means about 2 or 3 years :) http://www.webkit.org/blog/?p=2233preview=true The idea is that it would cover all the interesting things we've added, even if we think most people know about them. Feel free to edit the draft (if that's possible - otherwise email me), especially if there are features we've forgotten. Dean On 30/01/2013, at 8:03 AM, Alexis Menard ale...@webkit.org wrote: Hi, Last month I started working on supporting unprefixed CSS Transitions in WebKit. Today this work is guarded behind CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED enabled by default in trunk (but disabled in Chrome and probably release branches of other ports). After various patches we (Dean Jackson and myself) feel confident that the work on the transitions is ready for prime time. We still have bugs open in our bug tracker but that doesn't block the unprefixed version to go live. So the proposal is the following one : - Rename CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED to CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED to cover the future work for unprefixing the animations and the transforms (that I plan to focus after this). - Ship CSS Transitions unprefixed enabled by default with no feature flag to disable it. My proposal is tracked here : https://bugs.webkit.org/show_bug.cgi?id=108216 We can also be proud to say our implementation is maybe the most complete one (thanks to the various people involved). On a side note the usage of prefixed/unprefixed version is monitored through the FeatureObserver so we can later in the future have an idea of the usage and maybe remove the prefixed support. Thoughts? Patched landed : http://trac.webkit.org/changeset/141119 http://trac.webkit.org/changeset/140560 http://trac.webkit.org/changeset/140448 http://trac.webkit.org/changeset/140010 http://trac.webkit.org/changeset/139922 http://trac.webkit.org/changeset/139762 http://trac.webkit.org/changeset/139200 http://trac.webkit.org/changeset/139106 http://trac.webkit.org/changeset/139070 http://trac.webkit.org/changeset/138728 http://trac.webkit.org/changeset/138721 http://trac.webkit.org/changeset/138184 Thanks. -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling unprefixed CSS Transitions by default.
Thank you for sharing! It appears that unless you're logged into WordPress (I had to go dig up my credentials) you just get a 404. On Tue, Jan 29, 2013 at 6:17 PM, Dean Jackson d...@apple.com wrote: Related: when the unprefixed transitions are enabled by default, we plan to make a long-overdue blog post on Recent Updates to Transitions and Animations where recent means about 2 or 3 years :) http://www.webkit.org/blog/?p=2233preview=true The idea is that it would cover all the interesting things we've added, even if we think most people know about them. Feel free to edit the draft (if that's possible - otherwise email me), especially if there are features we've forgotten. Dean On 30/01/2013, at 8:03 AM, Alexis Menard ale...@webkit.org wrote: Hi, Last month I started working on supporting unprefixed CSS Transitions in WebKit. Today this work is guarded behind CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED enabled by default in trunk (but disabled in Chrome and probably release branches of other ports). After various patches we (Dean Jackson and myself) feel confident that the work on the transitions is ready for prime time. We still have bugs open in our bug tracker but that doesn't block the unprefixed version to go live. So the proposal is the following one : - Rename CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED to CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED to cover the future work for unprefixing the animations and the transforms (that I plan to focus after this). - Ship CSS Transitions unprefixed enabled by default with no feature flag to disable it. My proposal is tracked here : https://bugs.webkit.org/show_bug.cgi?id=108216 We can also be proud to say our implementation is maybe the most complete one (thanks to the various people involved). On a side note the usage of prefixed/unprefixed version is monitored through the FeatureObserver so we can later in the future have an idea of the usage and maybe remove the prefixed support. Thoughts? Patched landed : http://trac.webkit.org/changeset/141119 http://trac.webkit.org/changeset/140560 http://trac.webkit.org/changeset/140448 http://trac.webkit.org/changeset/140010 http://trac.webkit.org/changeset/139922 http://trac.webkit.org/changeset/139762 http://trac.webkit.org/changeset/139200 http://trac.webkit.org/changeset/139106 http://trac.webkit.org/changeset/139070 http://trac.webkit.org/changeset/138728 http://trac.webkit.org/changeset/138721 http://trac.webkit.org/changeset/138184 Thanks. -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Feature announcement: Custom Elements
Hi folks, I'm going to implement Custom Elements standard behind ENABLE(CUSTOM_ELEMENTS) flag. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html Here is the tracking bug for the feature: https://bugs.webkit.org/show_bug.cgi?id=99688 Note that Mozilla is also working on implementing this. https://bugzilla.mozilla.org/show_bug.cgi?id=783129 Let me know if you have any questions or comments. Bests, -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Remove webkitDashArray attribute from CanvasRenderingContext2d
On Jan 30, 2013, at 1:12 PM, Dean Jackson d...@apple.com wrote: On 30/01/2013, at 12:46 PM, Dirk Schulze dschu...@adobe.com wrote: Would it be possible to clean up the code a bit more and remove the prefixed attributes? I don't think they should be removed yet. As you mentioned, it's been 16 months which is at least one Safari release cycle. I'd prefer that we give a console warning for now. This sounds reasonable for me. Just as a note, if the next Safari release for iOS and Mac do not add this console warning, it may take another year before the code can be cleaned up. The impact is minimal so. Greetings, Dirk Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Breaking other ports
On Tue, Jan 29, 2013 at 5:46 PM, Adam Barth aba...@webkit.org wrote: I understand that the new rules of the road for WebKit2 are that contributors are allowed to break non-Apple ports. However, those new norms do not extend to WebCore. In http://trac.webkit.org/changeset/138962, Alexey broke form resubmission confirmation in the Chromium port. In https://bugs.webkit.org/show_bug.cgi?id=108214, he is refusing to fix the regression. I don't view that as acceptable behavior from a member of the WebKit community. I understand your frustration but I don't think he intentionally broke the feature given that neither EWS nor commit queue detected the regression. As far as I checked both of those bugs, there aren't even a Chromium test failing per his patch. So his patch broke something that had not been tested before. Also, given that the fix needs to Chromium port specific, it doesn't seem productive to ask Alexey, who presumably doesn't know much about Chromium port, to come up with a fix for it. And both of those bugs and https://code.google.com/p/chromium/issues/detail?id=172721 don't seem to contain any information as to why his patch broke the feature or what kind of changes he needs to make in order to fix it. Someone who knows how form resubmission confirmation works in Chromium needs to help him so that we can fix this regression. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Breaking other ports
On Tue, Jan 29, 2013 at 6:29 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jan 29, 2013 at 5:46 PM, Adam Barth aba...@webkit.org wrote: I understand that the new rules of the road for WebKit2 are that contributors are allowed to break non-Apple ports. However, those new norms do not extend to WebCore. In http://trac.webkit.org/changeset/138962, Alexey broke form resubmission confirmation in the Chromium port. In https://bugs.webkit.org/show_bug.cgi?id=108214, he is refusing to fix the regression. I don't view that as acceptable behavior from a member of the WebKit community. I understand your frustration but I don't think he intentionally broke the feature given that neither EWS nor commit queue detected the regression. I don't see Adam or anyone else implying that he intentionally broke a feature, but regardless when a patch to WebCore causes a regression in an upstream port the options are to investigate and fix the regression or roll the patch out. If Alexey doesn't want to look into the regression, which is valid, then the only clear option is to roll it out until someone who is familiar with the breakage can look at it. As far as I checked both of those bugs, there aren't even a Chromium test failing per his patch. So his patch broke something that had not been tested before. Also, given that the fix needs to Chromium port specific, it doesn't seem productive to ask Alexey, who presumably doesn't know much about Chromium port, to come up with a fix for it. And both of those bugs and https://code.google.com/p/chromium/issues/detail?id=172721 don't seem to contain any information as to why his patch broke the feature or what kind of changes he needs to make in order to fix it. Someone who knows how form resubmission confirmation works in Chromium needs to help him so that we can fix this regression. If Alexey is interested in learning about this and fixing it, that's fine, but in the meantime the regression can't be left in the tree. As long as I've been involved with the WebKit project there has been a strict no-regression policy. - James - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: Custom Elements
On Tue, Jan 29, 2013 at 6:22 PM, Hajime Morrita morr...@chromium.orgwrote: I'm going to implement Custom Elements standard behind ENABLE(CUSTOM_ELEMENTS) flag. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html Here is the tracking bug for the feature: https://bugs.webkit.org/show_bug.cgi?id=99688 Note that Mozilla is also working on implementing this. https://bugzilla.mozilla.org/show_bug.cgi?id=783129 Let me know if you have any questions or comments. Usually specs explain a bit what it is for and give examples toward that goal. Not this spec :( Can you please summarize what problem Custom Elements is solving for for lazy people like me? :) Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: Custom Elements
On Tue, Jan 29, 2013 at 7:21 PM, Benjamin Poulain benja...@webkit.orgwrote: On Tue, Jan 29, 2013 at 6:22 PM, Hajime Morrita morr...@chromium.orgwrote: I'm going to implement Custom Elements standard behind ENABLE(CUSTOM_ELEMENTS) flag. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html Here is the tracking bug for the feature: https://bugs.webkit.org/show_bug.cgi?id=99688 Note that Mozilla is also working on implementing this. https://bugzilla.mozilla.org/show_bug.cgi?id=783129 Let me know if you have any questions or comments. Usually specs explain a bit what it is for and give examples toward that goal. Not this spec :( This is all my fault. I've been focusing on getting the actual matter of the spec right, guided by Mozilla's implementation feedback. Can you please summarize what problem Custom Elements is solving for for lazy people like me? :) Custom elements are part of the bigger umbrella of Web Components. There's a nice document that explains how everything fits in to the Web Components--and here's the section on custom elements: http://www.w3.org/TR/components-intro/#custom-element-section Hope this helps! :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Breaking other ports
29.01.2013, в 17:46, Adam Barth aba...@webkit.org написал(а): In http://trac.webkit.org/changeset/138962, Alexey broke form resubmission confirmation in the Chromium port. In https://bugs.webkit.org/show_bug.cgi?id=108214, he is refusing to fix the regression. I don't view that as acceptable behavior from a member of the WebKit community. I can't remember any previous occasions where undiagnosed client breakage was expected to be investigated by another port's contributors. There is no indication that anything is wrong in WebKit yet. As a separate point, even in cases where you can expect patch author to do initial investigation, you probably won't get much by demanding to immediately address fallback from a three week old patch, or else. There was even no pressure from chromium release schedule as far as I can tell, as the changeset has already been rolled out of chromium release branch before you first commented on bugs.webkit.org. I hope this explains the matter. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: Custom Elements
On Jan 29, 2013, at 6:22 PM, Hajime Morrita morr...@chromium.org wrote: Hi folks, I'm going to implement Custom Elements standard behind ENABLE(CUSTOM_ELEMENTS) flag. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html For reference: will the feature flag be comprehensive, or will parts of the implementation/scaffolding be outside the ifdef? - Maciej Here is the tracking bug for the feature: https://bugs.webkit.org/show_bug.cgi?id=99688 Note that Mozilla is also working on implementing this. https://bugzilla.mozilla.org/show_bug.cgi?id=783129 Let me know if you have any questions or comments. Bests, -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Breaking other ports
On Jan 29, 2013, at 7:17 PM, James Robinson jam...@google.com wrote: On Tue, Jan 29, 2013 at 6:29 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jan 29, 2013 at 5:46 PM, Adam Barth aba...@webkit.org wrote: I understand that the new rules of the road for WebKit2 are that contributors are allowed to break non-Apple ports. However, those new norms do not extend to WebCore. In http://trac.webkit.org/changeset/138962, Alexey broke form resubmission confirmation in the Chromium port. In https://bugs.webkit.org/show_bug.cgi?id=108214, he is refusing to fix the regression. I don't view that as acceptable behavior from a member of the WebKit community. I understand your frustration but I don't think he intentionally broke the feature given that neither EWS nor commit queue detected the regression. I don't see Adam or anyone else implying that he intentionally broke a feature, but regardless when a patch to WebCore causes a regression in an upstream port the options are to investigate and fix the regression or roll the patch out. If Alexey doesn't want to look into the regression, which is valid, then the only clear option is to roll it out until someone who is familiar with the breakage can look at it. As far as I checked both of those bugs, there aren't even a Chromium test failing per his patch. So his patch broke something that had not been tested before. Also, given that the fix needs to Chromium port specific, it doesn't seem productive to ask Alexey, who presumably doesn't know much about Chromium port, to come up with a fix for it. And both of those bugs and https://code.google.com/p/chromium/issues/detail?id=172721 don't seem to contain any information as to why his patch broke the feature or what kind of changes he needs to make in order to fix it. Someone who knows how form resubmission confirmation works in Chromium needs to help him so that we can fix this regression. If Alexey is interested in learning about this and fixing it, that's fine, but in the meantime the regression can't be left in the tree. As long as I've been involved with the WebKit project there has been a strict no-regression policy. I agree that the regression should be fixed. But before we discuss that... I am puzzled by the apparent stance of Alexey must immediately fix this himself or we must revert immediately. That's not the standard we have applied in the past to changes that appear generally correct but end up breaking the UI of a client of a specific port. Let me give a specific example: In https://bugs.webkit.org/show_bug.cgi?id=45631 scroll events were changed to be asynchronous (as it happens, by a Google contributor). This broke a UI feature of Safari, resulting in https://bugs.webkit.org/show_bug.cgi?id=52988. This was, as in the more recent situation, a breakage not caught by WebKit tests or even any of our internal automated testing, but did break a feature in a way that we would have considered unacceptable for a stable release. Apple folks did not demand an immediate fix or revert in this case. Instead, we investigated what caused the breakage to happen, worked together with Google folks to discuss possible solutions, and in the end added a quirk specific to the Safari UI feature in question ourselves. The more preferred approach would have been to fix it downstream in Safari itself instead of adding a quirk to WebKit, but that turned out to be impractical. We did at one point suggest reverting when we thought the change broke a public website too, but promptly abandoned that position when it turned out that it was the site in question that was broken To me this example seems pretty parallel to the situation https://bugs.webkit.org/show_bug.cgi?id=108214. Can anyone explain to me why 108214 is being approached so much more aggressively than 52988. Granted, the symptom is somewhat more severe, but I expect the action leading to it is fairly uncommon. And it seems like Alexey's change is broadly correct, in that it fixes a race condition in cross-platform code. Perhaps it's just the fact that Adam and Alexey are both somewhat prone to needlessly inflammatory remarks? If so, perhaps we can simply find other engineers to work on this issue. It seems to me that the most positive way to resolve this particular issue would be if Chromium folks could help us understand why the change broke Chromium, and help us figure out if the right fix is a change to Chromium, or a particular change to WebKit. And also to be a little patient. I don't expect this will take the multiple months it took to resolve the scroll event issue, but a few days turnaround might be a bit much to expect. Nate suggested a possible workaround in a comment: https://bugs.webkit.org/show_bug.cgi?id=108214#c3. I uploaded a patch implementing this workaround to the bug. I would appreciate if any Chromium
