1686334 - Rejecting page load in onLoadRequest leaves page in invalid state

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P2)

Description

[[ex-Mozilla] Agi Sferro | :agi]

For context see https://bugzilla.mozilla.org/show_bug.cgi?id=1685403#c1 and following comments.

A summary of the issue is this:

• A page load is initiated for example.com/redir
• Extension code redirects this page load to moz-extension://...
• GeckoView Embedder rejects this page load by rejecting onLoadRequest: https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentLoadListener.cpp#2455

At this point the page is left into a state where the document is loaded from an extension page (at moz-extension) but the page thinks it's actually example.com, e.g. document.baseURI is example.com/redir and so is document.href.

Locking down the bug since this seems likely to be exploitable somehow.

Comment 1

[Daniel Veditz [:dveditz]]

From an alarmist view this could be a sec-high same-origin problem. Hopefully it will turn out to be more benign. (could also be a GeckoView issue rather than in Gecko itself -- why is it rejecting onLoadRequest after it's already created the page with contents?)

Comment 2

[Christian Holler (:decoder)]

Olli, can you comment on comment 0 and suggest a way to move forward here? Thanks!

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

How is the redirection handled in extension code? Does it not follow the normal redirection code paths?

Comment 4

[Rob Wu [:robwu]]

(In reply to Olli Pettay [:smaug] from comment #3)

How is the redirection handled in extension code? Does it not follow the normal redirection code paths?

The extension that triggers this is in https://bugzilla.mozilla.org/show_bug.cgi?id=1685403#c1

The onBeforeRequest event maps to the "http-on-modify-request" notification, and the actual redirection (in response to the redirectUrl property) are at https://searchfox.org/mozilla-central/rev/9ae77e4ce3378bd683ac9a86b729ea6b6bd22cb8/toolkit/components/extensions/webrequest/WebRequest.jsm#983,992-993,1003-1030

In C++, it starts at https://searchfox.org/mozilla-central/rev/9ae77e4ce3378bd683ac9a86b729ea6b6bd22cb8/toolkit/components/extensions/webrequest/ChannelWrapper.cpp#230,232-233

Comment 5

[Nika Layzell [:nika] (ni? for response)]

(In reply to Agi Sferro | :agi | ni? for questions | ⏰ PST | he/him from comment #0)

• GeckoView Embedder rejects this page load by rejecting onLoadRequest: https://searchfox.org/mozilla-central/source/netwerk/ipc/DocumentLoadListener.cpp#2455

Ah, it definitely looks like the code right now doesn't continue with the load, even in an errored state, if the promise is rejected here: https://searchfox.org/mozilla-central/rev/d9f6cded535d202a9ade4a530e653e659bcb5bbd/netwerk/ipc/DocumentLoadListener.cpp#2598-2605. I imagine that could lead to weirdness in some way or another.

In addition, it seems like perhaps the verify callback is happening too late. None of the other steps in the callback function for DocumentLoadListener are delayed by the async call into geckoview, only the one call to the async redirect callback. The new load may just continue. A quick reading of the code would suggest that the load should hang here, but it sounds from the description that it doesn't, which makes me wonder if the promise was never serving its purpose and delaying processing of the load after the redirect.

:mattwoodrow might remember some of the fiddly stuff we ended up needing to do with the document load listener and redirects, and whether or not my suspicions are correct.

Comment 6

[[ex-Mozilla] Agi Sferro | :agi]

Nika, was there a question for me?

Comment 7

[Matt Woodrow (:mattwoodrow)]

(In reply to Nika Layzell [:nika] (ni? for response) from comment #5)

Ah, it definitely looks like the code right now doesn't continue with the load, even in an errored state, if the promise is rejected here: https://searchfox.org/mozilla-central/rev/d9f6cded535d202a9ade4a530e653e659bcb5bbd/netwerk/ipc/DocumentLoadListener.cpp#2598-2605. I imagine that could lead to weirdness in some way or another.

That definitely seems like a problem, but should only happen if the java code stores an exception in the GeckoResult, rather than a valid AllowOrDeny value.

In addition, it seems like perhaps the verify callback is happening too late. None of the other steps in the callback function for DocumentLoadListener are delayed by the async call into geckoview, only the one call to the async redirect callback. The new load may just continue. A quick reading of the code would suggest that the load should hang here, but it sounds from the description that it doesn't, which makes me wonder if the promise was never serving its purpose and delaying processing of the load after the redirect.

:mattwoodrow might remember some of the fiddly stuff we ended up needing to do with the document load listener and redirects, and whether or not my suspicions are correct.

The redirected load should be suspended and blocked until it gets a OnRedirectVerifyCallback call (asynchronously, usually), so I wouldn't expect the load to just continue in the background. I do agree that things should be hanging if we actually rejected the promise (but I don't think that's the normal behaviour for rejecting an onLoadRequest call).

Comment 8

[Nika Layzell [:nika] (ni? for response)]

I'm unfortunately not super familiar with geckoview dev. Is there an easy way to run the POC on a local development build and/or how hard would it be to build a junit test or similar to test this particular situation? self-assigning so that I actually take a look at this once I figure out how to reproduce :-)

Comment 9

[Rob Wu [:robwu]]

Agi might know an easier way to get a build to reproduce this.

To manually reproduce this, you'd need to create a build and undo the patch at https://github.com/mozilla-mobile/android-components/pull/9381. When you have a working app running on your Android phone or emulator, then you can run the STR mentioned in comment 4 (i.e. https://bugzilla.mozilla.org/show_bug.cgi?id=1685403#c1). It has been a while since I have built an app from Android-Components, instructions to do so are here:

• https://firefox-source-docs.mozilla.org/mobile/android/geckoview/contributor/for-gecko-engineers.html
• https://firefox-source-docs.mozilla.org/mobile/android/geckoview/contributor/geckoview-quick-start.html#include-geckoview-as-a-dependency

But before going down that road, I suggest to wait for Agi to chime in (once he's back from PTO). That may save some time :)

Comment 10

[[ex-Mozilla] Agi Sferro | :agi]

Attachment: webRequest-redirect-to-extension-3.zip

You can reproduce this bug in GVE directly making this little change:

diff --git a/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java b/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java
index c80039f01234..25c5ac0d73e0 100644
--- a/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java
+++ b/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java
@@ -1945,6 +1945,11 @@ public class GeckoViewActivity
                   " isRedirect=" + request.isRedirect +
                   " isDirectNavigation=" + request.isDirectNavigation);
 
+            // Trigger the bug
+            if (request.uri.startsWith("jar:")) {
+                return GeckoResult.deny();
+            }
+
             return GeckoResult.allow();
         }

and then loading the extension using this command (I think the original bug has instructions to install web-ext):

web-ext run \                                                                                                
--target=firefox-android \
--android-device=emulator-5554 \
--firefox-apk org.mozilla.geckoview_example \
--firefox-apk-component=GeckoViewActivity

Note that the extension needs to have an icon (GVE bug) so I'm uploading an update to the extension so that you can run that.

Comment 11

[[ex-Mozilla] Agi Sferro | :agi]

Note that you still need to allow the extension to run in private browsing (three dots -> Settings -> Run Extensions in private tabs) and open a private tab (three dots -> check Private Browsing)

Comment 12

[Neha Kochar [:neha]]

Andreas is looking into this now.

Comment 13

[Andreas Farre [:farre]]

:agi, could you please give me access to bug 1685403

Comment 14

[Julien Cristau [:jcristau]]

cc:ed

Comment 15

[Andreas Farre [:farre]]

So I might have found a possible solution. The error isn't that GeckoView throws (an exceptional state also requires that the callback isn't called), after logging (and adding some logs of my own I can see:

...
07-06 15:48:42.102 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp Waiting until resume [this=700d60f27000]
07-06 15:48:42.102 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel [700d60f27000] created nsChannelClassifier [700d61811400]
07-06 15:48:42.102 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::Starting nsChannelClassifier 700d61811400 [this=700d60f27000]
07-06 15:48:42.103 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::SuspendInternal [this=700d60f27000]
07-06 15:48:42.109 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel DocumentChannelParent ctor [this=700d61354600]
07-06 15:48:42.110 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel DocumentChannelParent Init [this=700d61354600, uri=http://example.com/redir]
07-06 15:48:42.111 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::OnLookupComplete [this=700d60f27000] prefetch complete: success status[0x0]
07-06 15:48:42.112 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::ResumeInternal [this=700d60f27000]
07-06 15:48:42.112 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::ResumeInternal [this=700d60f27000]
07-06 15:48:42.112 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp 700d60f27000 called from script: resource://gre/modules/WebRequest.jsm:1018:20
07-06 15:48:42.112 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp HttpBaseChannel::RedirectTo [this=700d60f27000, uri=moz-extension://2b8d4351-d9e7-4056-9768-5dbecf5a0fbe/subdir/test.html]
07-06 15:48:42.112 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp 700d60f27000 called from script: resource://gre/modules/WebRequest.jsm:1019:20
07-06 15:48:42.112 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::StartRedirectChannelToURI()
07-06 15:48:42.112 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::SetupReplacementChannel [this=700d60f27000 newChannel=700d60fcf480 preserveMethod=1]
07-06 15:48:42.112 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp HttpBaseChannel::SetupReplacementChannel [this=700d60f27000 newChannel=700d60fcf480 preserveMethod=1]
07-06 15:48:42.112 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::WaitForRedirectCallback [this=700d60f27000]
07-06 15:48:42.112 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel DocumentLoadListener::AsyncOnChannelRedirect [this=700d652ba4c0 flags=2]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel DocumentLoadListener AsyncOnChannelRedirect [this=700d652ba4c0, uri=jar:file:///data/local/tmp/web-ext-artifacts-1625582869067/redirect_redir_to_extension_page-1.xpi!/subdir/test.html] redirect vetoed
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::OnRedirectVerifyCallback [this=700d60f27000] result=80004004 stack=1 WaitingForRedirectCallback=1
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::ContinueAsyncRedirectChannelToURI [this=700d60f27000]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::Cancel [this=700d60f27000 status=80004004]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp HttpBaseChannel::DoNotifyListener this=700d60f27000
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel ParentProcessDocumentOpenInfo OnStartRequest [this=700d60fa9900]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel ParentProcessDocumentOpenInfo OnDocumentStartRequest [this=700d60fa9900]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp ParentChannelListener::OnStartRequest [this=700d61353e80]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel DocumentLoadListener OnStartRequest [this=700d652ba4c0]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp nsHttpChannel::SuspendInternal [this=700d60f27000]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel DocumentLoadListener::TriggerRedirectToRealChannel [this=700d652ba4c0] aDestinationProcess=-1
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel DocumentLoadListener RedirectToRealChannel [this=700d652ba4c0] aRedirectFlags=4, aLoadFlags=2d0004
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp HttpBaseChannel::SetApplyConversion [this=700d60f27000 value=0]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp ParentChannelListener::OnStopRequest: [this=700d61353e80 status=2147500036]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel DocumentLoadListener OnStopRequest [this=700d652ba4c0]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: D/nsHttp nsHttpHandler::NotifyObservers [chan=700d60f27040 event="http-on-stop-request"]
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/nsHttp HttpBaseChannel::RemoveAsNonTailRequest this=700d60f27000, rc=700d626943c0, already added=1
07-06 15:48:42.118 10846 10862 I Gecko   : [Parent 10846: Main Thread]: V/DocumentChannel ParentProcessDocumentOpenInfo dtor [this=700d60fa9900]
07-06 15:48:42.119 10876 10895 I Gecko   : [Child 10876: Main Thread]: V/DocumentChannel DocumentChannelChild RecvRedirectToRealChannel [this=700d75820ab0, uri=http://example.com/redir]
07-06 15:48:42.119 10876 10895 I Gecko   : [Child 10876: Main Thread]: D/nsHttp nsHttpHandler::NewProxiedChannel [proxyInfo=0]
...

so the issue seems to be that we pseudo resume the load, even though nsIAsyncVerifyRedirectCallback.onRedirectVerifyCallback vetoed the redirect. So I'm not sure what's expected bahaviour here, but if it is http://example.com/redir as before the extension tried to redirect, it seems that what is needed is to update the state of DocumentLoadListener to something that reflects the vetoed state. This is just hacking on my part, but updating DocumentLoadListener::mChannelCreationURI to the uri o aOldChannel accomplishes a load of an unredirected http://example.com/redir.

Matt, do you have any thoughts about this?

Comment 16

[Andreas Farre [:farre]]

Need info for :nika, by request!

I haven't found an actual way to reproduce this outside of GVE, but to at least get logs from GVE is fairly straightforward.

Just install all the android pre-reqs using ./mach bootstrap, make a mozconfig for android[1], ./mach build and wait. ./mach run will then prompt you to start the emulator.

web-ext can be installed from npm.

After that it's just to add the code from comment 10 and run the STRs. Here I also added the trick :nika told me about to add logging in xpcom/base/Logging.cpp, since we can't use the usual env-passing due to us using web-ext to install the extension.

As a final note, after making changes, but before running web-ext one needs to run an extra ./mach run, otherwise GVE won't be updated to include the new changes. I'm dreaming of ./mach web-ext [PATH] that can do both, including env passing.

[1]:

ac_add_options --with-java-bin-path=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.272.b10-0.fc31.x86_64/bin
ac_add_options --enable-application=mobile/android
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-android-release
ac_add_options --target=x86_64

Comment 17

[Matt Woodrow (:mattwoodrow)]

(In reply to Andreas Farre [:farre] (PTO until 2021-08-08) from comment #15)

Matt, do you have any thoughts about this?

I think that all makes sense, we probably shouldn't be mutating mChannelCreationURI, unless the redirect actually succeeds.

We do need to make a copy of the value during AsyncOnChannelRedirect though, since at that point it returns the moz-extension: URI, but after this callback will return http://example.com/redir.

I think want to copy it into separate storage somewhere, and then copy again to mChannelCreationURI once we're sure that the redirect actually happened.

Comment 18

[Andreas Farre [:farre]]

Cool, then I'll make that happen. Thanks!

Comment 19

[Andreas Farre [:farre]]

This turns out to be a bit more complicated than expected. In the end it has nothing to do with GeckoView, or the GeckoView code that allows us to veto a redirect. Instead of trying this on Android, I switched to just add:

@@ -2463,6 +2463,13 @@ DocumentLoadListener::AsyncOnChannelRedirect(
   // redirect, as it can't apply anymore.
   mRemoteTypeOverride.reset();
 
+ nsCOMPtr<nsIURI> uriBeingLoaded =
+      AntiTrackingUtils::MaybeGetDocumentURIBeingLoaded(aNewChannel);
+  if (uriBeingLoaded->SchemeIs("jar")) {
+    MOZ_DBG("aborting");
+    aCallback->OnRedirectVerifyCallback(NS_ERROR_ABORT);
+    return NS_OK;
+  }
 #ifdef ANDROID

which behaves exactly the same, with the same bad behaviour. And the attached extension works for desktop as well.

And to be fair I'm not entirely sure of if it has to do with DocumentLoadListener either. It is indeed so that resetting mChannelCreationURI solves the issue with AsyncOnChannelRedirect redirecting to extension resources with a bad uri (and document.location), but it isn´t an actual fix since it instead stops the load at about:blank.

If you look at the documentation for nsIAsyncVerifyRedirectCallback.onRedirectVerifyCallback[1] and ChannelEventSink.asyncOnChannelRedirect[2] there is a passage that indicates that calling aCallback->onRedirectVerifyCallback(NS_ERROR_ABORT) (or any kind of error result) should do just that. Stop loading the new channel, but continuing on the old[3]. We seem to do neither. Also, it looks like we do indeed end up cancelling the old channel by default, if we have any status other than success[4]. In fact the wording at [4] seems to indicate that not resuming the load on the old channel is expected behaviour.

It's at this point that I'm starting to run out of ideas. I have a pernosco recording of this[5] that has my patch to veto the redirect, and I've tried to summarise my findings there. Adding :dragana and :mattwoodrow hoping that you have insights. Here's my questions:

Matt, can you see any way that DocumentLoadListener/PDocumentChannel circumvents the assumptions in [1] and [2] that makes us behave this way? Except from resetting mChannelCreationURI. Note that resetting the channel isn't needed since it's done in DocumentLoadListener::OnStartRequest.

Dragana, can you see anything that I'm obviously missing? Is the vetoing intended to be used in this way, or should a veto always indicate Cancel.

Thanks for any help I can get on this, and also, if this turns out to be out of scope for DocumentLoadListener I'd be really happy if I could pass this on to someone with a little bit more domain knowledge than myself.

[1] https://searchfox.org/mozilla-central/source/netwerk/base/nsIAsyncVerifyRedirectCallback.idl
[2] https://searchfox.org/mozilla-central/source/netwerk/base/nsIChannelEventSink.idl
[3] https://searchfox.org/mozilla-central/source/netwerk/base/nsIChannelEventSink.idl#61-66
[4] https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#2841
[5] https://pernos.co/debug/GCBCPKSkZ9i9FmVx4DwHCg/index.html#f{m[ApxW,AacXpw_,t[AQ,KYw_,f{e[ApxW,AacLoA_,s{af30PQpAA,bAZc,uAioB9g,oAjntHQ___

Comment 20

[Andreas Farre [:farre]]

:honza, you've been doing work with particularly the nsIAsyncVerifyRedirectCallback. Do you have any insight to this?

Comment 21

[Dragana Damjanovic [:dragana]]

(In reply to Andreas Farre [:farre] from comment #20)

:honza, you've been doing work with particularly the nsIAsyncVerifyRedirectCallback. Do you have any insight to this?

This is wrong Honza, but also the other Honza is not active anymore. I will take a look.

Comment 22

[Andreas Farre [:farre]]

Anny, this is a shot in the dark, but could this have to do with that loads not stopping for discarded canonical browsing contexts?

Comment 23

[Anny Gakhokidze [:annyG]]

Andreas, since you were able to reproduce this issue, could you add the following code (1) here in CanonicalBrowsingContext.cpp to see if that solves the issue? I'm still not super familiar with the redirection code path so I'm not sure whether or not it will work.

(1)

  if (mCurrentLoad) {
    mCurrentLoad->Cancel(NS_BINDING_ABORTED);
  }

Comment 24

[Andreas Farre [:farre]]

Attachment: withextension.png

I tried this again, and if I'm not mistaken it's looking better. And then I didn't even add the code from comment 23. I'll run mozregression tomorrow to see what's actually happened here.

It does look like the page understands that it is an extension now. Maybe it was too long ago that I looked at this so that I don't remember correctly. Will investigate. Thanks Anny!

Comment 25

[Anny Gakhokidze [:annyG]]

As mentioned during one of the meetings, this seems to be the same problem I tried to fix in bug 1721217, see this comment below:

... if a redirection fails to take place, we don't revert back the mChannelCreationURI in DocumentLoadListener ... I briefly tried to add a channelCreationURI getter to nsIChannel where it returns the value of OriginalURI at the time AsyncOpen method was called [but] there were a lot of other test issues that I need to look at....

... I filed a follow up bug 1735613 to fix this [android test mentioned in bug 1721217] ... where I will address the problem of mChannelCreationURI not being reverted back.

I will continue working on bug 1735613 (adding a channelCreationURI getter to nsIChannel) once I post patches for bug 1721217 for review. Posting this here so that once I'm done with 1735613, we can check here to see if this bug has been resolved.

Comment 26

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Anny Gakhokidze [:annyG] from comment #25)

As mentioned during one of the meetings, this seems to be the same problem I tried to fix in bug 1721217, see this comment below:

... if a redirection fails to take place, we don't revert back the mChannelCreationURI in DocumentLoadListener ... I briefly tried to add a channelCreationURI getter to nsIChannel where it returns the value of OriginalURI at the time AsyncOpen method was called [but] there were a lot of other test issues that I need to look at....

... I filed a follow up bug 1735613 to fix this [android test mentioned in bug 1721217] ... where I will address the problem of mChannelCreationURI not being reverted back.

I will continue working on bug 1735613 (adding a channelCreationURI getter to nsIChannel) once I post patches for bug 1721217 for review. Posting this here so that once I'm done with 1735613, we can check here to see if this bug has been resolved.

Anny is currently working on bug 1735613.

Comment 27

[Andreas Farre [:farre]]

I've tried a patch from Anny from bug 1735613, and with that patch and the extra code from comment 10, denying the redirect haves us stay on the page that we're trying to load from, which should be correct, right?

Anny, thanks for the help with this! Do you think we should close this bug, or wait a bit and resolve it as duplicate a bit later?

Comment 28

[Anny Gakhokidze [:annyG]]

thanks for testing this, andreas! I think we can wait a bit and then resolve it as a duplicate, once I land the other patches. I can make myself the assignee and take responsibility for resolving this bug.

Comment 29

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Status update: Anny tried to landed prerequisite patches for bug 1735613 but got backed out due to test failures. She is investigating the failures.

Comment 30

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Anny, since now bug 1735613 was fixed, anything left here before we can close this?

Comment 31

[Anny Gakhokidze [:annyG]]

To be completely sure, I would like to ask Agi to please confirm that this bug was indeed fixed before we close this. Andreas tested it on the latest central and said the bug is fixed "if the expected result of rejecting a load in onLoadRequest is to not load anything".

Comment 32

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Assigning :afarre to follow up. Thank you.

Comment 33

[[ex-Mozilla] Agi Sferro | :agi]

I can confirm I cannot reproduce the bug anymore.

Comment 34

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Daniel, can you please suggest the proper way to close this bug? It's verified that this is resolved by a non-sec bug 1735613. Thank you.

Comment 35

[BugBot [:suhaib / :marco/ :calixte]]

As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.

Please visit this google form to reply.