User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Actual results:

The moz-extension url will not display in the url bar of the cloned tab.

Expected results:

The moz-extension url should display in the url bar of the cloned tab.

Version 70.0a1
Build-ID 20190803221448

I have also seen that the back button is greyed out (like disabled), but right-clicking on it will show the history menu items (as expected).

I have only seen this issue one time.

I cannot reproduce the problem.

STR:

1. Install https://addons.mozilla.org/en-US/firefox/addon/viewerjs-we/
2. Google for "filetype:odt"
3. Click on the odt file.
4. Right-click on the tab, duplicate

Expected:

• Tab is duplicated, URL contains "moz-extension"

Actual:

• As expected. (the video from the report shows that the original request URL is shown instead of moz-extension:).

The extension redirects to web-accessible moz-extension URL on webRequest.onHeadersReceived. I don't see anything immediately obvious going on.

You need some back history for this bug to appear.

If i reload the cloned tab, then the url bar will show the moz-extension url (as expected).

With my STR, I still have back history. Note: I tested on Firefox 68 and Nightly 70.a1 buildID 20190724095428 on Linux.

Can you provide steps to reproduce? And is this only reproducible on Nightly, or also release? Does this also happen on a new Firefox profile?
Since I am not able to reproduce, and you seem to be able to consistently reproduce it, could you use mozregression to find when the issue started occurring?

(and since you mentioned "back history", does bug 1561711 have any relevance here?)

(In reply to Rob Wu [:robwu] from comment #6)

With my STR, I still have back history.

No, the back history will not be lost.

Note: I tested on Firefox 68 and Nightly 70.a1 buildID 20190724095428 on Linux.

I tested again on Firefox 68 and the bug also happens on release.

(and since you mentioned "back history", does bug 1561711 have any relevance here?)

No, this does not have anything to do with bug 1561711.

If i reload the duplicated tab, then the back history is not lost.

Maybe the bug does not happen on linux?

Does this also happen on a new Firefox profile?

It also happens on a new profile.

Maybe some softvision.ro user can help?

Can you provide steps to reproduce?

Just open some urls. It maybe needs some time, for the bug to occur.

When i was testing on Firefox 68, it needed some time, for the bug to occur.

Without reliable reproduction steps, this issue cannot be investigated.

If you are able to somewhat reliably reproduce the problem on your computer, please try to see if it worked before on older Firefox versions.
You can use mozregression to find the specific Firefox build where the functionality started to break.

See https://mozilla.github.io/mozregression/

I was able to reproduce the issue following the steps from comment #3 on both Win10x64 and Linux 18.04.2 LTS , using FF 70.0a1 (2019-08-07) (64-bit).

I will attach a video of the issue.

Also , I performed a bisection using mozregression and it looks like the problem is here : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=26598a115edd552ce42fe28561d7b71158f06298&tochange=d05c6310d573658af4a4f2cee332bb01732fcabf

After several attempts, I observed the issue on Firefox 68.0.1, Ubuntu 18.0.2 using STR from comment 3.
It seems that the awesomebar is in editing mode (even though it is not focused). When I focus the awesomebar, and press Escape to "end" the input, then the expected moz-extension:-URL is shown.

Marking as a regression by bug 1509906 based on comment 11.

Gijs, any idea what could be happening here?

(In reply to Rob Wu [:robwu] from comment #13)

Marking as a regression by bug 1509906 based on comment 11.

Gijs, any idea what could be happening here?

No. The change in https://hg.mozilla.org/integration/autoland/rev/d05c6310d573658af4a4f2cee332bb01732fcabf only affects the initial tab, and it looks like this isn't the initial tab in the window, and the duplicated tab definitely isn't the initial tab, so I don't see how that change could have any effect here. I suspect the regression window is wrong.

Whether we think the URL has been edited normally has to do with the userTypedValue and urlbarChangeTracker state kept on the <browser>, in case that helps. I don't know if/how/why anything would go wrong here, but that's where I'd start looking.

When I reproduce this, it looks like the tab in which the document is first opened still has a web remoteType, whereas the duplicated tab has an extension remoteType.

I'd start by looking at why the tab doesn't get remoteness-switched when the moz-extension viewer loads - that seems wrong. If that's expected for web-accessible resources, then the next question is why the duplicated tab doesn't keep the same remoteness. Rob, can you clarify this?

The wrong URL is shown because something has set the userTypedValue on the duplicate/new browser to the google URL. I don't know how that happened, either.

TBF, I think there is likely some underlying kind of problem with the remoteness switching that might not be specific to webextensions. See also e.g. bug 1402418.

The remoteType issue looks like a bug of its own, and I filed it as bug 1573456.

Victor, could you try to find a regression range again?

I performed another bisection and this is what it returned : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=88f4a687f0393b33602c65c36635f58301261366&tochange=49f22f8f91f901d0fe46753f7f920b460df5b87b

Thanks for the bisection. None of the items in that regression range are suspect.

Could you try again? At least for me, the reproduction rate was far from 100% reliable, so just to be sure you may want to double or triple-check at every step whether the issue was really (not) reproduced, and at the end try again to see if you get the same range again.

kernp: Is this a (recent) regression in your mind? Or are you not sure (e.g. because you haven't tried the steps-to-reproduce before).

I did another mozregression on Windows10x64 with next results : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8517649053392155b1812af4500c23ef4876f52f&tochange=06463d10abdee48650cbe28ae63e957951430412 .

Also , Rob tried on Linux with a Firefox60 and he was able to reproduce the issue on this older version too.

I found an odt file for which the reproduction rate was 100% on affected builds(use it after installing the https://addons.mozilla.org/en-US/firefox/addon/viewerjs-we/ addon) :
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&cad=rja&uact=8&ved=2ahUKEwj24brNxYLkAhV0w8QBHfLpDN0QFjAGegQIARAC&url=http%3A%2F%2Fwww.elgrecotour.sk%2Fdodatok.odt&usg=AOvVaw1iFaBKlFUYFpObBLWHbAbD

This is not a recent regression.

I can reliably reproduce as follows:

1. Extract the attached zip file (it contains the extension and redir.html)
2. Load the extension, via about:debugging or with web-ext run.
3. Open a new tab.
4. Focus the location bar, and type or paste the location of redir.html (file:-URL or http:-URL both work).
   (this also works: data:text/html,<meta http-equiv=refresh content="0;URL=http://example.com/slow">)
5. Navigate to the specified URL (e.g. by pressing Enter, or by clicking the arrow button).
   (redir.html will redirect to example.com, and the extension will redirect the response to a moz-extension:-page)
6. When the moz-extension:-page shows up, right-click on the tab and Duplicate the tab.
7. Look at the location bar

Expected:

• moz-extension:-URL

Actual:

• The URL from step 4.

More info: The displayed URL is not necessarily the requested resource (redir.html). It is anything that was entered in the location bar. So if I type/paste file:///tmp/path/to/webRequest-redirect-slow/ (directory from step 1), and click on redir.html, then after duplicating the tab the originally typed URL is shown (not redir.html).

When I type/paste a http: or data:-URL and press Alt-Enter to navigate to it in a new tab, then the issue does not occur.
When I type/paste a file:-URL and press Alt-Enter to navigate to it in a new tab, then the issue occurs.

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

This still feels sessionstore / remoteness-switching-related to me, also given bug 1402418. Seems like restoreTabContent ends up doing the wrong thing somehow. This is going to get more and more important once fission ramps up. Mike, any chance you have cycles to investigate further here? There's detailed STR in comment #20; comment #14 may or may not have other helpful background.

Sorry Gijs, doesn't look like I'll have the cycles to look at this soonish. The remoteness-switching bits are not really my area, since mconley has introduced them and probably knows more.

(In reply to :Gijs (he/him) from comment #22)

This still feels sessionstore / remoteness-switching-related to me, also given bug 1402418. Seems like restoreTabContent ends up doing the wrong thing somehow. This is going to get more and more important once fission ramps up. Mike, any chance you have cycles to investigate further here? There's detailed STR in comment #20; comment #14 may or may not have other helpful background.

Alright, over to other Mike per comment #23...

I've put this on the fission-frontend backlog for investigation.

Tentatively tracking for Fission Nightly (M6)

Gijs, can I retriage this into sessionstore or something?

(In reply to Shane Caraveo (:mixedpuppy) from comment #27)

Gijs, can I retriage this into sessionstore or something?

Sure, though I'm afraid it'll just languish here instead, so I don't think that really helps. What this bug needs is an assignee.

Gijs, is this bug just a visual issue with the moz-extension URL in the address bar? Or are there more serious side effects?

Do you think this bug needs to block shipping Fission to Release? If so, does it also need to block enabling Fission in Nightly?

(In reply to Chris Peterson [:cpeterson] from comment #29)

Gijs, is this bug just a visual issue with the moz-extension URL in the address bar? Or are there more serious side effects?

There are some more issues in the sense that the URL bar is supposed to give you truthful information about what's loaded in the tab, and it doesn't do that anymore, and there's no obvious way for the user to fix that. It also means that hitting enter in the URL bar now loads the "wrong" thing.

Do you think this bug needs to block shipping Fission to Release?

Maybe. AIUI this bug reproduces without enabling Fission. It seems related to process switching, so it may also manifest in other ways under fission. Like, right now, this seems to affect file: tabs and moz-extension: ones. My worry is that with fission it'll happen for other cases, too, because under fission there'll be a lot more process switches.

If so, does it also need to block enabling Fission in Nightly?

No.

(bouncing ni in case you want to adjust the fission milestone)

(In reply to :Gijs (he/him) from comment #30)

Do you think this bug needs to block shipping Fission to Release?

Maybe. AIUI this bug reproduces without enabling Fission. It seems related to process switching, so it may also manifest in other ways under fission. Like, right now, this seems to affect file: tabs and moz-extension: ones. My worry is that with fission it'll happen for other cases, too, because under fission there'll be a lot more process switches.

If so, does it also need to block enabling Fission in Nightly?

No.

Thanks. I'll move this bug to Fission M7 (Beta blocker) so we can revisit whether this bug should block riding the trains, if it's not fixed by then. Sounds like we should investigate what related cases might be broken by Fission process switches.

I'll see if I can find time to at least diagnose this.

Like bug 1402418, this is actually fixed already on beta and nightly. It seems to be a combination of bug 1597154 and bug 1627420