Bump markupsafe from 2.0.1 to 2.1.1 in /docs#1
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [markupsafe](https://github.com/pallets/markupsafe) from 2.0.1 to 2.1.1. - [Release notes](https://github.com/pallets/markupsafe/releases) - [Changelog](https://github.com/pallets/markupsafe/blob/main/CHANGES.rst) - [Commits](pallets/markupsafe@2.0.1...2.1.1) --- updated-dependencies: - dependency-name: markupsafe dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
youennf
pushed a commit
that referenced
this pull request
Jul 29, 2022
See [1] for the origin of this change, which makes it possible to
trigger pop up hide animations from within the `hide` event handler.
For example:
popup.addEventListener('hide', () => {
popup.animate({
transform: 'translateY(-50px)',
opacity: 0,
}, 200);
});
To accomplish that, the hide process now looks like this:
1. Capture any already-running animations via getAnimations(),
including animations on descendent elements.
2. Remove the :top-layer pseudo class.
3. Fire the 'hide' event.
4. If the hidePopup() call is *not* the result of the pop-up being
"forced out" of the top layer, e.g. by a modal dialog or fullscreen
element:
a. Restore focus to the previously-focused element.
b. Update style. (Animations/transitions start here.)
c. Call getAnimations() again, remove any from step #1, and then wait
until all of them finish or are cancelled.
5. Remove the pop-up from the top layer, and add the UA display:none
style.
6. Update style.
[1] https://chromium-review.googlesource.com/c/chromium/src/+/3688871/9/third_party/blink/renderer/core/dom/element.cc#2660
Bug: 1307772
Change-Id: I910535b13cfc3c8f8498ed64dae73caa75dd7317
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3708419
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Commit-Queue: Robert Flack <flackr@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1018685}
youennf
pushed a commit
that referenced
this pull request
Dec 15, 2022
******************************************************************
*** SHERIFFS: please don't revert this CL if it causes web_tests
to flake/fail. If that happens, the cause is a bad
test. Please mark that test as flaky/fail in
TestExpectations, with a new crbug. Please block the
new bug against crbug.com/1395228. Thanks!
******************************************************************
Prior to this CL, a test like this:
```
<script>
window.onload = () => {
test((t) => { ... }, 'test 1');
test((t) => { ... }, 'test 2');
test((t) => { ... }, 'test 3');
};
</script>
```
would not run anything after test #1. The issue is that the testharness
immediately adds a window load handler that marks `all_loaded = true`,
and that ends the tests as soon as the first result from the first test
is processed. (The test runner waits for the first test because
`Tests.prototype.all_done()` also waits until `this.tests.length > 0`.)
There were various mitigating corner cases, such as if you started
the list of tests with a promise_test(), that would increment a
counter that kept the rest of the tests alive. Etc.
With this CL, the testharness-added window.onload handler runs a
setTimeout(0), so that `all_loaded` is only set to true after all of
the tests are loaded by any window.onload handler.
This exposed a few tests that should have been failing but were
masked by the lack of test coverage - bugs have been filed for
those. Also, several tests that were working around this via various
means are also cleaned up in this CL. I'm sure there are more of
those.
Bug: 1395228,1395226,1307772
Change-Id: I6f12b5922186af4e1e06808ad23b47ceac68559c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4074305
Reviewed-by: Weizhong Xia <weizhong@google.com>
Auto-Submit: Mason Freed <masonf@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1081558}
youennf
pushed a commit
that referenced
this pull request
Jan 10, 2023
This reverts commit 4a03c6c459fdbf11976a424aa02a1d094484134c. Reason for revert: This has caused tests in upstream WPT to fail, blocking unrelated PRs. It was still possible to upstream this because those tests weren't triggered on the change due to a bug: web-platform-tests#37623 There was an attempted fix for this: web-platform-tests#37549 But, quoting jgraham from the WPT Matrix chat: > the actual fix failed a test I wrote and now I need to spend some more time investigating Original change's description: > WPT: Allow `window.onload` to contain multiple `test()`s > > ****************************************************************** > *** SHERIFFS: please don't revert this CL if it causes web_tests > to flake/fail. If that happens, the cause is a bad > test. Please mark that test as flaky/fail in > TestExpectations, with a new crbug. Please block the > new bug against crbug.com/1395228. Thanks! > ****************************************************************** > > Prior to this CL, a test like this: > > ``` > <script> > window.onload = () => { > test((t) => { ... }, 'test 1'); > test((t) => { ... }, 'test 2'); > test((t) => { ... }, 'test 3'); > }; > </script> > ``` > > would not run anything after test #1. The issue is that the testharness > immediately adds a window load handler that marks `all_loaded = true`, > and that ends the tests as soon as the first result from the first test > is processed. (The test runner waits for the first test because > `Tests.prototype.all_done()` also waits until `this.tests.length > 0`.) > There were various mitigating corner cases, such as if you started > the list of tests with a promise_test(), that would increment a > counter that kept the rest of the tests alive. Etc. > > With this CL, the testharness-added window.onload handler runs a > setTimeout(0), so that `all_loaded` is only set to true after all of > the tests are loaded by any window.onload handler. > > This exposed a few tests that should have been failing but were > masked by the lack of test coverage - bugs have been filed for > those. Also, several tests that were working around this via various > means are also cleaned up in this CL. I'm sure there are more of > those. > > Bug: 1395228,1395226,1307772 > Change-Id: I6f12b5922186af4e1e06808ad23b47ceac68559c > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4074305 > Reviewed-by: Weizhong Xia <weizhong@google.com> > Auto-Submit: Mason Freed <masonf@chromium.org> > Reviewed-by: Mason Freed <masonf@chromium.org> > Commit-Queue: Mason Freed <masonf@chromium.org> > Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1081558} Bug: 1395228,1395226,1307772 Change-Id: Icbddad3a8bb47473bcbc331f424661b9041addf2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4111318 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Philip Jägenstedt <foolip@chromium.org> Cr-Commit-Position: refs/heads/main@{#1085925}
youennf
pushed a commit
that referenced
this pull request
Jan 10, 2023
In the case that a popover contains an invoker that points back to that invoker, the tab navigation code used to get confused. E.g.: ``` <div id="menu" popover> <button autofocus popoverhidetarget="menu">Button #1</button> <button popoverhidetarget="menu">Button #2</button> </div> ``` In this case, trying to tab between the first and second button would break because the second button appeared to be an invoker for a new popover, when in reality it was an invoker for the same popover. Fixed: 1399601 Bug: 1307772 Change-Id: I276370d7c8eee0dd32f0c89da202a0d3777bf911 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4133482 Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1089080}
Author
|
Superseded by #230. |
youennf
pushed a commit
that referenced
this pull request
Jun 22, 2023
…each time of the loop There are 2 possible scenarios which are not handled by the method. 1. Moving content node to new `<blockquote>` has already been moved to outside of the editing host. 2. There is no container to insert new `<blockquote>`, e.g., in an inline editing host. In the case #1, we should ignore the ex-child node. In the case #2, we should abort it. Note that Chrome inserts `<blockquote>` even if there is no proper container. However, such behavior is disagreed in interop-2023. Therefore, it's okay just to abort it for now. Depends on D180781 Differential Revision: https://phabricator.services.mozilla.com/D180782 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1756237 gecko-commit: 42f3f3ab11b47f1d56d8bcd6a128398539dd1f23 gecko-reviewers: m_kato
youennf
pushed a commit
that referenced
this pull request
Jun 22, 2023
…eb-platform-tests#40504) * [wdspec] browsingContext.print: fix rounding error in page.py test [pytest](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/webdriver/tests/support/image.py) uses: def cm_to_px(cm): return round(cm * 96 / 2.54) [js](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/tools/wptrunner/wptrunner/print_pdf_runner.html) uses: const viewport = page.getViewport({ scale: 96. / 72. }); ... canvas.height = viewport.height; canvas.width = viewport.width; This produces a rounding error, even though the dimension is correct: > assert cm_to_px(expected_dimensions["height"]) == height E assert 454 == 453 E +454 E -453 The inconsistency of rounding in both ends becomes clear when we eliminate "round" in the pytest side: > assert cm_to_px(expected_dimensions["height"]) == height E assert 453.54330708661416 == 453 E +453.54330708661416 E -453 There are multiple ways to fix this issue. Option #1: Use "floor" instead of "round" in pytest. Option #2: Use a range in the assertion comparison, allowing a difference of up to +-1.0. This is what this PR does. The comparison is performed in [`assert_pdf_dimensions`](https://github.com/web-platform-tests/wpt/blob/b6107cc1ac8b9c2800b4c8e58af719b8e4d9b8db/webdriver/tests/support/fixtures_bidi.py#L210). The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333.... * use floor in cm_to_px instead of round * compare to floor and to round instead of a range * Revert "compare to floor and to round instead of a range" This reverts commit 63f894e. * Revert "use floor in cm_to_px instead of round" This reverts commit 7e65d91.
youennf
pushed a commit
that referenced
this pull request
Aug 25, 2023
Because of the order of operations for Clone(), previous to this CL, the typical sequence would be: 1. Clone the element 2. Clone the children of the element (recursing to step #1). 3. AppendChild() each cloned child to its parent cloned element. 4. (in the caller of Clone) AppendChild the cloned element to its eventual parent. Because each AppendChild triggers a call to Node::InsertedInto() for *all descendants of the appended element* [1], the fact that the tree is constructed bottom-up (leaf nodes first) means that InsertedInto() is called N^2 times, where N is the depth of the cloned tree. Because clone-and-append is a very common pattern, this CL adds an `append_to` argument to `Clone()`, which appends to the parent before appending the children. This CL also adds a perf test for this scenario (cloning a deep tree). Locally, on a debug build, this test gives 0.13 runs/s before this CL, and 0.40 runs/s after, for a 3.1X speedup. [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=1006;drc=5d60017dba57e86d477634812e1340127734f8a7 Bug: 1453291 Change-Id: Icdd75c45aa5ecc4fe8bb5d1ff0b7a2b27bec2171 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4728983 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1177922}
youennf
pushed a commit
that referenced
this pull request
Apr 30, 2024
…rners We had two issues: 1. Before we had fast rounded corners, we always created mask layers for rounded corner clips, and the mask layer made the scroll begin unreliable and fall back to the main thread. With fast rounded corners, the scrolls were treated as reliable without checking if the point is in or out of the rounded corners. 2. If the scroller has a rounded corner by itself (instead of from an ancestor), as we only create InnerBorderRadiusClip for the contents, the compositor doesn't actually know which part of the layer bounds is transparent to hit test (e.g. if the scroller has a border which is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness, such layers have HitTestOpaqueness::kMixed. This CL changes the behavior of LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from FindLayerUpToFirstScrollableOrOpaqueToHitTest): - For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the layer is affected by any fast rounded corners; - For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only OpaqueToHitTest() (without checking IsScrollerOrScrollbar()) because a hit test on a scrollable layer is reliable only if it's opaque to hit test. Bug: 40277896 Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5466909 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Steve Kobes <skobes@chromium.org> Cr-Commit-Position: refs/heads/main@{#1291538}
youennf
pushed a commit
that referenced
this pull request
Aug 26, 2024
Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use the shadow tree of web-exposed shadow root, instead of using light DOM elements of the host. Bug #2: aRange could possibly create mCrossShadowBoundaryRange first (due to boundaries are in different tree), and later moves the boundaries to the same tree. When this happens, we should remove mCrossShadowBoundaryRange and use the default range to represent it. Differential Revision: https://phabricator.services.mozilla.com/D207608 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1891783 gecko-commit: 0f54a84c32d1c22d71ff7307944b824639adbd6f gecko-reviewers: jjaschke, smaug, dom-core
youennf
pushed a commit
that referenced
this pull request
Aug 26, 2024
Since @page border box layout objects aren't in the the layout tree, any code that wants to walk up the tree to find the containing block will be in for a surprise. This would happen if percentage-based @page padding was used [1]. Recomputing padding during painting when we have already done it during layout is rather pointless anyway. Read it out directly from the fragment. [1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent() #2 blink::LayoutBoxModelObject::ComputedCSSPadding() #3 blink::LayoutBoxModelObject::PaddingTop() #4 blink::LayoutBoxModelObject::PaddingOutsets() #5 blink::BoxPainterBase::PaintFillLayer() #6 blink::BoxPainterBase::PaintFillLayers() #7 blink::BoxFragmentPainter::PaintBackground() Bug: 40286153 Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1300711}
youennf
pushed a commit
that referenced
this pull request
Aug 26, 2024
WebRTC is one form of network communication that should be disabled when window.fence.disableUntrustedNetwork is called in a fenced frame. However, 1. We don't have any identified use cases for WebRTC in fenced frames 2. The revocation process would be more involved than other forms of network access, which would provide little benefit per #1. 3. Entirely disabling WebRTC PeerConnection instead is beneficial for privacy and does not break existing fenced frame use cases. This CL disables RTCPeerConnection construction entirely in fenced frames, regardless of whether window.fence.disableUntrustedNetwork was called or not. The change is behind an existing flag so that it does not ship until other forms of network revocation do. Disabling RTCPeerConnection *can* be handled entirely by the renderer, but a compromised renderer could potentially circumvent this to construct a peer connection anyway. A follow-up CL will add a browser-side control to ensure that this does not occur. Change-Id: Iaa2caaddeee70852179332dd89c5dbbac3ffcfbf Bug: 41488151 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5527514 Reviewed-by: Guido Urdaneta <guidou@chromium.org> Commit-Queue: Andrew Verge <averge@chromium.org> Reviewed-by: Liam Brady <lbrady@google.com> Reviewed-by: Shivani Sharma <shivanisha@chromium.org> Cr-Commit-Position: refs/heads/main@{#1319162}
youennf
pushed a commit
that referenced
this pull request
Nov 27, 2024
See https://drafts.csswg.org/css-pseudo-4/#first-text-line 1. For a block container that establishes an inline formatting context, the "first formatted line" is its first line box, if it has one. Otherwise, there is no first formatted line. 2. Otherwise, for a block container that has block children, look inside the first in-flow block child (if any) and do #1 if it establishes an inline formatting context. Otherwise, do #2. In short, we don't need to search for line boxes in blocks after the first block child. If there is no line in the first child, there's no "first formatted line". There's no spec for "last formatted line", but apply the same logic. I.e. if the last block child has no line, there's no "last formatted line". This allows us to simplify things a bit, especially when it comes to re-laying out (kTextBoxTrimEndDidNotApply). The only case where we need this now is for blocks inside inlines: If the last formatted line is inside a block-in-inline, we need to go back and re-lay it out if it turns out to be the last line (which isn't something we can check inside block-in-inline layout). Note: When adding support for block fragmentation, trimming at a fragmentainer's block end will be another case where we need to re-lay out. The motivation for this change was text box trimming inside block fragmentation (upcoming CL), and be able to add support for that and still be reasonably confident that it won't become too complicated. This fixes one existing test. Some other existing tests had to be updated because of this change (they were making incorrect assumptions about first/last formatted line). As a result of that, some new refs had to be added, since other tests were piggy-backing on the same ref. Bug: 40254880, 367766472 Change-Id: I3fcc53af86353725b1f5705a5528493a72bf2e69 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952979 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/main@{#1373765}
youennf
pushed a commit
that referenced
this pull request
Nov 27, 2024
This implements the core Sanitizer logic. This is still missing spec-mandated handling of "javascript:" URLs, and will have to be updated as the spec develops. But other than that, the basics are now there. ------------------ This a re-land of crrev.com/c/5922125. Patch set #1 is the original version, as reviewed and submitted there. Patch set #2 contains the fix. Analysis of the bug is in https://issues.chromium.org/issues/356601280#comment16 Bug: 356601280, 379235386, 379246316 Change-Id: I06d4a9a378330cc76015e3922b9e288d9503881a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6021482 Reviewed-by: Yifan Luo <lyf@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/main@{#1385522}
youennf
pushed a commit
that referenced
this pull request
Apr 1, 2025
Remove AILanguageDetectorFactory and expose create and availability statically on LanguageDetector. This is a followup change to CLs crrev.com/c/6402873, crrev.com/c/6402775. Note: This change is a cherry-pick of crrev.com/c/6397965. Some changes have been made as part of rebasing + fixing previous CQ test failures. PS #1 represents the cherry-picked change prior to rebase + minor edits. Fixed: 402165734 Change-Id: Id384ebe31ccfe9e0efd65dd7c890cd66875a9ed8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6403274 Reviewed-by: Mike Wasserman <msw@chromium.org> Commit-Queue: Christine Hollingsworth <christinesm@chromium.org> Cr-Commit-Position: refs/heads/main@{#1439000}
youennf
pushed a commit
that referenced
this pull request
Jun 17, 2025
This is a preparation change to the upcoming change that disallows non-trustworthy plaintext HTTP prerendering. This CL now runs external/wpt/speculation-rules/ wpts over HTTPs. Bug: 340895233 Change-Id: Id820f192f5e973245c2dbbf1ca8daa5078abad78 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6398184 Reviewed-by: Domenic Denicola <domenic@chromium.org> Reviewed-by: Fabio Rocha <fabio.rocha@microsoft.com> Commit-Queue: Jessica Chen <peiche@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1450755}
youennf
pushed a commit
that referenced
this pull request
Nov 5, 2025
…& compile_module_script to fix the inline script reporting wrong line issue (web-platform-tests#39415) Originally, the function compile_module_script hardwires the value 1 when invoking CompileOptionsWrapper::new(). This is fine if the script is written in separate JS file, but for inline scripts, it will cause confusion if the <script> tag doesn't start from line #1. Credits to JDM for actually pointing out which functions to fix. Testing: There are WPT tests for this change, specifically: tests/wpt/tests/html/semantics/scripting-1/the-script-element/module/evaluation-error-5.html Signed-off-by: RichardTjokroutomo <richard.tjokro2@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps markupsafe from 2.0.1 to 2.1.1.
Release notes
Sourced from markupsafe's releases.
Changelog
Sourced from markupsafe's changelog.
Commits
b90a42erelease version 2.1.1b15d9d6avoid ambiguous regex in striptags9ddec7aupdates go to 2.1.xb5a5175Merge pull request #281 from pallets/release-2.1.0e281553release version 2.1.0db10c66unpin pytestd44534bMerge branch '2.0.x'd713248add pip-compile-multi verify hook6c17ee8Merge pull request #278 from msimacek/mainaae7d82disable speedups for GraalPythonDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)