Closed Bug 1556377 Opened 3 years ago Closed 2 years ago

URL shown in address bar does not match URL visited

Categories

(Core :: Networking, defect, P1)

69 Branch
defect
Points:
5

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr60 --- unaffected
firefox67 --- unaffected
firefox67.0.1 --- unaffected
firefox68 --- unaffected
firefox69 + fixed

People

(Reporter: abovens, Unassigned)

References

Details

(4 keywords)

  1. Go to https://slack-redir.net/link?url=https%3A%2F%2Faddons.mozilla.org

Expected result

The page redirects to https://addons.mozilla.org/ (etc.)

Actual result

An addons.mozilla.org error page is shown (even the search box works!), while the domain shown in the address bar is slack-redir.net

When I loaded this the first time, I couldn't reproduce and it seemed fine.

Loading that again in new tabs subsequent times, I'm seeing the issue that Andreas defines.

On the browser console, I'm seeing various loads:

GET https://slack-redir.net/link?url=https%3A%2F%2Faddons.mozilla.org (returns 302)
GET https://addons.mozilla.org/ (returns 301)
GET https://addons.mozilla.org/en-GB/firefox/ (returns 200)

There's then various other loads, all returning 200.

This is with the latest nightly build, Mac 10.14 69.0a1 (2019-06-02) (64-bit), with QuantumBar enabled.

Can't repro on beta or earlier nightlies (5-30), but reproduces on today's, so adding regression keywords. A narrower window would probably help pinpoint what's going on here, but off-hand I suspect changes from bug 1510569.

Points: --- → 5
Priority: -- → P1

My first mozregression pointed me at the backout of bug 1551601... and if I set browser.tabs.remote.useHTTPResponseProcessSelection to false, the problem goes away... Not sure why it's pointing me to a backout though...

Flags: needinfo?(valentin.gosu)

Note: for reproducing, I'm generally finding that you have to load the redirect twice (I do in separate tabs) for it to show up. So it may be something to do with caching of the redirect.

I've just tried mozregression based on Gijs' range and using --bad 2019-06-03 --good 2019-05-30

That leads to https://hg.mozilla.org/integration/mozilla-inbound/rev/b23e6c13ffb9ac2a5b4add1676988ec191a4fde3 which is a backout of bug 1551601 that landed on 28th May.

It is a little weird though, that a backout seems to have caused this regression.

Can someone verify the regression range? Unfortunately I haven't got time to do it now.

(In reply to Mark Banner (:standard8) from comment #5)

Note: for reproducing, I'm generally finding that you have to load the redirect twice (I do in separate tabs) for it to show up. So it may be something to do with caching of the redirect.

I've just tried mozregression based on Gijs' range and using --bad 2019-06-03 --good 2019-05-30

That leads to https://hg.mozilla.org/integration/mozilla-inbound/rev/b23e6c13ffb9ac2a5b4add1676988ec191a4fde3 which is a backout of bug 1551601 that landed on 28th May.

It is a little weird though, that a backout seems to have caused this regression.

Can someone verify the regression range? Unfortunately I haven't got time to do it now.

This is the same as Marco's, so it seems accurate enough to me. Let's just ask :kats and :valentin to have a look.

Also let's move to networking land...

Group: firefox-core-security → network-core-security
Component: Address Bar → Networking
Flags: needinfo?(kats)
Product: Firefox → Core

Presumably bug 1551601 is fixing this problem, but I backed it out for other regressions. I don't know the details of what that patch does, so leaving needinfo for valentin to respond. I expect the corrected fix, when it lands, will still fix this bug.

Flags: needinfo?(kats)

Huh, that's interesting. I can't reproduce it in Nightly, but I can in a clean build. I wonder if there's an addon interfering with the bug.

I'll try to make sure the fix for bug 1551601 also fixes this one.
It would be very helpful if we could have an automated test for this.

It could also be related to bug 1552012. (redirect issue)

Duplicate of this bug: 1556955

[Tracking Requested - why for this release]: The address bar may show the wrong url

Andreas, can you still reproduce it in Nighly?
I don't see it in any of last few builds.

Flags: needinfo?(valentin.gosu) → needinfo?(abovens)

could be fixed by bug 1551601

It works fine for me!

Flags: needinfo?(abovens)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME

Can we open this up?

Flags: needinfo?(dveditz)
Group: network-core-security
Flags: needinfo?(dveditz)
You need to log in before you can comment on or make changes to this bug.