Branch: refs/heads/webkitglib/2.38 Home: https://github.com/WebKit/WebKit Commit: 04f1427d62940f56aa9d2b4b5a75aa3b56886bf9 https://github.com/WebKit/WebKit/commit/04f1427d62940f56aa9d2b4b5a75aa3b56886bf9 Author: Philippe Normand <ph...@igalia.com> Date: 2023-02-01 (Wed, 01 Feb 2023)
Changed paths: M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.h Log Message: ----------- Cherry-pick 259473@main (e534395cf34a). https://bugs.webkit.org/show_bug.cgi?id=251145 [GStreamer][WebRTC] Missing null/zero checks in 1.22 code paths https://bugs.webkit.org/show_bug.cgi?id=251145 Reviewed by Xabier Rodriguez-Calvar. * Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp: (WebCore::GStreamerMediaEndpoint::addRemoteStream): The msid property can be null, so needs checking. (WebCore::GStreamerMediaEndpoint::requestAuxiliarySender): Remove auxiliary sender caching. This code is called once per transport stream, ownership of the sender is passed to the caller. Canonical link: https://commits.webkit.org/259473@main Commit: dfe7f9fc1a6df42bb4628a7b5d609563a9dde5a1 https://github.com/WebKit/WebKit/commit/dfe7f9fc1a6df42bb4628a7b5d609563a9dde5a1 Author: moggiesir <21014913+moggie...@users.noreply.github.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WTF/wtf/glib/GUniquePtr.h M Source/WebKit/UIProcess/API/gtk/PageClientImpl.cpp M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp M Source/WebKit/UIProcess/API/gtk/WebKitWebViewBasePrivate.h Log Message: ----------- Cherry-pick 259530@main (dbc31d00f78f). https://bugs.webkit.org/show_bug.cgi?id=243924 Fix async scroll event propagation for GTK4 https://bugs.webkit.org/show_bug.cgi?id=243924 https://bugs.webkit.org/show_bug.cgi?id=245616 Reviewed by Michael Catanzaro. Since GTK offers no way to asynchronously decide on whether an event should be propagated or stopped and webkit doesn't want to block the UiProcess on event handing in the WebProcess, webkit2gtk needs to use a bit of a hacky workaround. This involves returning GDK_EVENT_STOP to the original event handling, sending the event to the WebProcess for handling, which then asynchronously determines whether the event was handled. If not, the webkit scroll handler is informed that the "next" scroll event should be propagated instead of handled+stopped, then re-emits the event for handling by GTK's run loop. This works fine in GTK3 because there's an API to immediately run the event loop for a given event (ensuring that the next event that the handler sees is the intended one). For GTK4, the API for re-inserting an event appends the event to the end of the event queue (despite what the documentation says), meaning the next event the handler sees may not be the intended event - thus the wrong event gets propagated and the just re-added event gets sent to the WebProcess again. This coupled with the fact that GDK4 will synthesize scroll-start/scroll-end events in some cases to ensure scroll events allows have the scroll-start, scroll, scroll-end sequence can easily cause loops since it's not just 1 event that needs to be propagated, it's up to 3. To work better with the APIs that exist for GTK4, it seems like the best option is to track the set of events that are "pending propagation" instead of relying on the tight interlock of just ignoring the "next" event. The key handling potentially also needs to be addressed similarly. Unfortunately, even tracking the set of events to ignore is challenging because GTK4 can compress/coalesce scroll events, meaning there will inevitably be some cases where we won't propagate events that otherwise maybe should have been propagated (and "unhandled" scroll events may cause some faster/slower than expected scrolling when they get compressed into an not-yet-handled events). Canonical link: https://commits.webkit.org/259530@main Commit: 184939c0c30e2b02f18eff6305386b274ec5ff88 https://github.com/WebKit/WebKit/commit/184939c0c30e2b02f18eff6305386b274ec5ff88 Author: Przemyslaw Gorszkowski <pgorszkow...@igalia.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp Log Message: ----------- Cherry-pick 259570@main (b69cf1887dfb). https://bugs.webkit.org/show_bug.cgi?id=250559 Remove item from cache of SQLiteStorageArea https://bugs.webkit.org/show_bug.cgi?id=250559 Reviewed by Sihui Liu. When Storage.removeItem method from Storage API is called, the cached value in SQLiteStorageArea should be also removed. It prevents increase the memory usage by network process. * Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp: (WebKit::SQLiteStorageArea::removeItem): Canonical link: https://commits.webkit.org/259570@main Commit: e62d93acba7d9e4fefd302272da9cd4425878804 https://github.com/WebKit/WebKit/commit/e62d93acba7d9e4fefd302272da9cd4425878804 Author: Antoine Quint <grao...@webkit.org> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WebCore/platform/animation/TimingFunction.h Log Message: ----------- Cherry-pick 259559@main (8f690bd4d728). https://bugs.webkit.org/show_bug.cgi?id=251352 imported/w3c/web-platform-tests/css/css-transitions/parsing/transition-timing-function-computed.html crashes (libc++ assertions) https://bugs.webkit.org/show_bug.cgi?id=251352 Reviewed by Antti Koivisto and Chris Dumez. We have a `m_stepPosition == otherSteps.m_stepPosition` check in TimingFunction::operator==(const TimingFunction&) which would catch the case where both m_stepPosition and otherSteps.m_stepPosition, which are std::optional<>, would not hold a value. However, we would hit a recently-enabled libc++ assertion (see bug 245692) because of the check `*m_stepPosition == StepPosition::End && !otherSteps.m_stepPosition`. Indeed, it is possible for otherSteps.m_stepPosition to hold a value while m_stepPosition does not. We simply reverse the two clauses such that we test `!otherSteps.m_stepPosition` first since we already know from earlier that `otherSteps.m_stepPosition` and `m_stepPosition` cannot both not hold a value. * Source/WebCore/platform/animation/TimingFunction.h: Canonical link: https://commits.webkit.org/259559@main Commit: 3357277343dd07d1eddcfa8bb22ef9a256c104a6 https://github.com/WebKit/WebKit/commit/3357277343dd07d1eddcfa8bb22ef9a256c104a6 Author: Przemyslaw Gorszkowski <pgorszkow...@igalia.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp M Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.h M Tools/TestWebKitAPI/Tests/WebKitGLib/TestWebsiteData.cpp Log Message: ----------- Cherry-pick 259573@main (d5346d022b5c). https://bugs.webkit.org/show_bug.cgi?id=250470 Restore/recreate corrupted SQLite file of local storage https://bugs.webkit.org/show_bug.cgi?id=250470 Reviewed by Sihui Liu. The current implementation in case of corrupted database file of the localstorage requires few restart to make it works again. This fix solves it and if the database file of the localstorage is currupted it deletes broken file. * Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.cpp: (WebKit::SQLiteStorageArea::prepareDatabase): (WebKit::SQLiteStorageArea::getItemFromDatabase): (WebKit::SQLiteStorageArea::allItems): (WebKit::SQLiteStorageArea::setItem): (WebKit::SQLiteStorageArea::removeItem): (WebKit::SQLiteStorageArea::clear): (WebKit::SQLiteStorageArea::handleDatabaseCorruption): * Source/WebKit/NetworkProcess/storage/SQLiteStorageArea.h: Canonical link: https://commits.webkit.org/259573@main Commit: 1b298f455c14082b016450e905161a06afdf1536 https://github.com/WebKit/WebKit/commit/1b298f455c14082b016450e905161a06afdf1536 Author: Vitaly Dyachkov <vit...@igalia.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WebCore/platform/graphics/WidthIterator.cpp Log Message: ----------- Cherry-pick 259618@main (f7b4df2d3a2c). https://bugs.webkit.org/show_bug.cgi?id=251009 `InlineTextBox`es containing `Zero Width Joiner`, `Zero Width Non-Joiner`, or `Zero Width No-Break Space` characters must not use simplified text measuring https://bugs.webkit.org/show_bug.cgi?id=251009 Reviewed by Alan Baradlay. When calculating the width of an InlineTexBox using simplified measuring, we simply sum up the width of every glyph. Some fonts (at least FreeType fonts) specify the non-zero width of `Zero Width Joiner`, `Zero Width Non-Joiner`, and `Zero Width No-Break Space`. Later, during the rendering, these glyphs are skipped causing the `InlineTextBox`es to become wider than they should be. Originally, `WidthIterator::characterCanUseSimplifiedTextMeasuring` was returning `false` for these characters. It was flipped by https://commits.webkit.org/241351@main along with `New Line` and `Carriage Return`. Fixes `css2.1/20110323/word-spacing-characters-003.htm` for WPE port. * Source/WebCore/platform/graphics/WidthIterator.cpp: (WebCore::WidthIterator::characterCanUseSimplifiedTextMeasuring): Canonical link: https://commits.webkit.org/259618@main Commit: ac92f874099d6d71ca47646cdccbade03ee82dfa https://github.com/WebKit/WebKit/commit/ac92f874099d6d71ca47646cdccbade03ee82dfa Author: Philippe Normand <ph...@igalia.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp M Source/WebCore/platform/graphics/gstreamer/mse/GStreamerMediaDescription.h Log Message: ----------- Cherry-pick 259620@main (13ac0f7d87c8). https://bugs.webkit.org/show_bug.cgi?id=251360 [GStreamer][MSE] Replace raw pointer with GRefPtr in GStreamerMediaDescription constructor https://bugs.webkit.org/show_bug.cgi?id=251360 Reviewed by Xabier Rodriguez-Calvar. The caps are already stored internally as a GRefPtr, so it's safer to pass a GRefPtr to the constructor as well. * Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp: (WebCore::AppendPipeline::didReceiveInitializationSegment): * Source/WebCore/platform/graphics/gstreamer/mse/GStreamerMediaDescription.h: (WebCore::GStreamerMediaDescription::create): (WebCore::GStreamerMediaDescription::GStreamerMediaDescription): Canonical link: https://commits.webkit.org/259620@main Commit: de57793477ec2b7f497ae7a8eb2ec8decdd8ec66 https://github.com/WebKit/WebKit/commit/de57793477ec2b7f497ae7a8eb2ec8decdd8ec66 Author: Sammy Gill <sammy.g...@apple.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: A LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/images/abs-pos-transferred-max-width-from-percentage-max-height-in-auto-height-containing-block-expected.html A LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/images/abs-pos-transferred-max-width-from-percentage-max-height-in-auto-height-containing-block.html M Source/WebCore/rendering/RenderBox.cpp Log Message: ----------- Cherry-pick 259663@main (93e6542aebf9). https://bugs.webkit.org/show_bug.cgi?id=251419 (REGRESSION(257434@main): https://readwise.io/read image squished https://bugs.webkit.org/show_bug.cgi?id=251419 rdar://103481329 Reviewed by Alan Baradlay. When viewing the website on iOS the image of the phone renders incorrectly as the width that is computed is too large. The image has max-height: 100%, so this constraint should also provide the transferred max-width for the image. We should be able to compute this value since the image is absolutely positioned. The previous version (before the regression) of this code computed the "constrained width" by calling computeReplacedLogicalHeight and then using the intrinsic ratio to compute the final width. computeReplacedLogicalHeight eventually called into computeReplacedLogicalHeightUsing to compute the min/max heights. This ended up computing the correct value for the min/max heights when the image was absolutely positioned and had a percentage height in an auto-height containing block. The new version of the code, which used the logic for the css aspect-ratio property, did not handle this case correctly and returned an incorrect value for max-height. To resolve this issue, we can check to see if the object is a RenderReplaced object by the time we get to RenderBox::computeLogicalHeightUsing and then call into computeReplacedLogicalHeightUsing to get the correct value. * LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/images/abs-pos-transferred-max-width-from-percentage-max-height-in-auto-height-containing-block-expected.html: Added. * LayoutTests/imported/w3c/web-platform-tests/html/rendering/replaced-elements/images/abs-pos-transferred-max-width-from-percentage-max-height-in-auto-height-containing-block.html: Added. * Source/WebCore/rendering/RenderBox.cpp: (WebCore::RenderBox::computeLogicalHeightUsing const): Canonical link: https://commits.webkit.org/259663@main Commit: 9d64763262d11dd9a8f8ed6d8f150f708d5b35cd https://github.com/WebKit/WebKit/commit/9d64763262d11dd9a8f8ed6d8f150f708d5b35cd Author: Philippe Normand <ph...@igalia.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp M Source/WebCore/platform/graphics/gstreamer/VideoSinkGStreamer.cpp M Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoEncoder.cpp Log Message: ----------- Cherry-pick 259672@main (ad178f924e78). https://bugs.webkit.org/show_bug.cgi?id=251446 [GStreamer] Missing chain-ups to parent class constructed in custom GStreamer elements https://bugs.webkit.org/show_bug.cgi?id=251446 Reviewed by Xabier Rodriguez-Calvar. * Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp: (webKitWebAudioSrcConstructed): * Source/WebCore/platform/graphics/gstreamer/VideoSinkGStreamer.cpp: (webkitVideoSinkConstructed): * Source/WebCore/platform/gstreamer/VideoEncoderPrivateGStreamer.cpp: (videoEncoderConstructed): * Source/WebCore/platform/gstreamer/WebKitFliteSourceGStreamer.cpp: (webkitFliteSrcConstructed): Canonical link: https://commits.webkit.org/259672@main Commit: 547d99b6fa412ab73d6c9bce86a95115243d8df2 https://github.com/WebKit/WebKit/commit/547d99b6fa412ab73d6c9bce86a95115243d8df2 Author: Philippe Normand <ph...@igalia.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WebCore/platform/mediastream/gstreamer/GStreamerWebRTCProvider.cpp Log Message: ----------- Cherry-pick 259677@main (abe64b617c46). https://bugs.webkit.org/show_bug.cgi?id=251496 [GStreamer][WebRTC] WebRTCProvider might be triggered on uninitialized GStreamer runtime https://bugs.webkit.org/show_bug.cgi?id=251496 Reviewed by Xabier Rodriguez-Calvar. Make sure GStreamer has been initialized before probing the video encoding capabilities. * Source/WebCore/platform/mediastream/gstreamer/GStreamerWebRTCProvider.cpp: (WebCore::GStreamerWebRTCProvider::initializeVideoEncodingCapabilities): Canonical link: https://commits.webkit.org/259677@main Commit: 6791312b00b99f88bb6fe69d4aeedff9ebb77e5d https://github.com/WebKit/WebKit/commit/6791312b00b99f88bb6fe69d4aeedff9ebb77e5d Author: Philippe Normand <ph...@igalia.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WebCore/Modules/mediastream/gstreamer/GStreamerStatsCollector.cpp Log Message: ----------- Cherry-pick 259680@main (33dd5dfb48a0). https://bugs.webkit.org/show_bug.cgi?id=251497 [GStreamer][WebRTC] Crash in statistics handling on RPi3 https://bugs.webkit.org/show_bug.cgi?id=251497 Reviewed by Xabier Rodriguez-Calvar. * Source/WebCore/Modules/mediastream/gstreamer/GStreamerStatsCollector.cpp: (WebCore::fillRTCCandidatePairStats): The state field is not optional, so for the time being fill it with a value not necessarily corresponding to the real platform state. Canonical link: https://commits.webkit.org/259680@main Commit: 78204cf5a1d5fcef86b14eefb525d0b98a7293eb https://github.com/WebKit/WebKit/commit/78204cf5a1d5fcef86b14eefb525d0b98a7293eb Author: Chirag M Shah <chirag_m_s...@apple.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: A LayoutTests/svg/foreignObject/foreign-object-without-svgroot-crash-expected.txt A LayoutTests/svg/foreignObject/foreign-object-without-svgroot-crash.html M Source/WebCore/svg/SVGForeignObjectElement.cpp Log Message: ----------- Cherry-pick 259685@main (e80607696660). https://bugs.webkit.org/show_bug.cgi?id=241778 Don't create renderer for foreignElement when it has no parent https://bugs.webkit.org/show_bug.cgi?id=241778 rdar://102916021 Reviewed by Nikolas Zimmermann. If the body is replaced by foreignElement, it results in a DOM which doesn't have anything to render or layout, but it crashes WebKit because we trip over an assert because isPaintOffsetCacheEnabled is not disabled (which happens only when there is a SVGRoot). This change makes it so that we don't generate the useless renderer in the first place, which is what happens with other SVGElements. * LayoutTests/svg/foreignObject/foreign-object-without-svgroot-crash-expected.txt: Added. * LayoutTests/svg/foreignObject/foreign-object-without-svgroot-crash.html: Added. * Source/WebCore/svg/SVGForeignObjectElement.cpp: (WebCore::SVGForeignObjectElement::rendererIsNeeded): Canonical link: https://commits.webkit.org/259685@main Commit: daacc0aad2e3928ba8fb6fc44029c4125ad529fc https://github.com/WebKit/WebKit/commit/daacc0aad2e3928ba8fb6fc44029c4125ad529fc Author: Michael Catanzaro <mcatanz...@redhat.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp Log Message: ----------- Cherry-pick 259683@main (0fc62415db20). https://bugs.webkit.org/show_bug.cgi?id=251456 [GLib] Always mount injected bundle directory in sandbox https://bugs.webkit.org/show_bug.cgi?id=251456 Reviewed by Carlos Garcia Campos. Incredibly, we somehow never noticed that the injected bundle is not always mounted in the sandbox. It's not very useful if it cannot be loaded. * Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp: (webkitWebContextConstructed): Canonical link: https://commits.webkit.org/259683@main Commit: 9293a4e88efd412a81975238da280e62d59c3ef6 https://github.com/WebKit/WebKit/commit/9293a4e88efd412a81975238da280e62d59c3ef6 Author: Chris Dumez <cdu...@apple.com> Date: 2023-02-01 (Wed, 01 Feb 2023) Changed paths: M Source/WebCore/html/track/VTTCue.cpp Log Message: ----------- Cherry-pick 259704@main (1a9f2a2c95a6). https://bugs.webkit.org/show_bug.cgi?id=251476 Fix bug in VTTCue::toJSON() found by new libcpp assertions https://bugs.webkit.org/show_bug.cgi?id=251476 rdar://104893184 Reviewed by Jer Noble. Fix bug in VTTCue::toJSON() found by new libcpp assertions. This was causing media/track/track-extended-descriptions.html to crash on some bots. The if condition was reversed. * Source/WebCore/html/track/VTTCue.cpp: (WebCore::VTTCue::toJSON const): Canonical link: https://commits.webkit.org/259704@main Compare: https://github.com/WebKit/WebKit/compare/f9fd2a39a365...9293a4e88efd _______________________________________________ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes