Closed Bug 1553962 Opened 6 years ago Closed 5 years ago

Fish shell’s fish_config no longer working

Categories

(Core :: DOM: Content Processes, defect, P3)

69 Branch
defect

Tracking

()

RESOLVED FIXED
Fission Milestone M5

People

(Reporter: robin, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

From within a fish shell (https://fishshell.com/) type fish_config and hit enter

Actual results:

Firefox opens a new tab with location file:///Users/robin/.cache/fish/web_config-Z2S1ID.html (obviously user dependent) with the unstyled config menu and nothing else. Console displays a message like this for each script file it’s trying to load:

Loading failed for the <script> with source “file:///Users/robin/.cache/fish/js/angular.js”.

Expected results:

Copying the same initial file:// URL into Chrome or Safari doesn’t show any problems. Scripts should load and display the config pages.

No time to bisect at the moment, sorry.

For reference, the file at that URL is something along the lines of:

<!DOCTYPE html>
<html>
 <head>
  <meta http-equiv="refresh" content="0;URL='http://localhost:8000/e9d81a35460055f6a4d557c0a9bc50bf/'" />
 </head>
 <body>
  <p><a href="http://localhost:8000/e9d81a35460055f6a4d557c0a9bc50bf/">Start the Fish Web config</a></p>
 </body>
</html>

Hi, I tried to reproduce this issue but when I access fish shell link: (https://fishshell.com/) > Try in Browser > Launch > Type fish_config > nothing happens.
Can you please provide some extra steps on how I can reproduce this issue.
Please try to test with a new profile on Nightly, you have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Thank you.

Flags: needinfo?(robin)

The Try in Browser functionality probably doesn't have the backend component hooked up - you'll need to install fish locally (brew install fish, apt install fish, or similar), so it can run a local webserver that you can connect to by running fish_config.

I can reproduce the problem with a clean profile on Firefox Nightly 69.0a1 (2019-05-29) (64-bit), but it works on 66.0.5 (64-bit). The fish version in both cases is 3.0.2-1220-gee9e5d49 (from Git master).

fish_config starts a small web server listening on the localhost interface, writes out a small HTML file (as seen above) which redirects to the server, and launches the browser to point to that file. In the nightlies the redirect appears to happen, but the browser location doesn't look like it gets updated, so the JS files get requested from the wrong path.

A simple reproduction is:

  1. Create a file in your home directory or wherever:
<!DOCTYPE html>
<html>
 <head>
  <meta http-equiv="refresh" content="0;URL='http://localhost:8001/'" />
 </head>
 <body>
	 <p>This is a redirect page.</p>
 </body>
</html>
  1. Run a Python server on localhost:
python -m http.server 8001
  1. Open the file you created in step 1 by using File > Open File... or similar

  2. Observe that you get a directory listing from the Python server, but that the document URL is still a file:// URL and document.location is still file:///Users/david/foo.html (or whatever your local file is called). Observe the lack of stylesheet and images - if you click on a directory the location will be updated and you will get a nicer view.

(By the way, massive kudos on how much easier it is to get Firefox development builds than it used to be; I haven't done any Firefox development in many years but the process was much smoother than I remember. I'm sure that wasn't easy!)

OK, mozregression is incredible.

It looks like with browser.tabs.remote.useHTTPResponseProcessSelection set to True, the problem occurs. Disabling it fixes the issue.

In my report above I made a mistake about the stylesheet/images, but the URL bar is where the problem is visible.

Confirming that flipping browser.tabs.remote.useHTTPResponseProcessSelection to true fixes this issue for me. I guess the question to ask is why?

Flags: needinfo?(robin)

Is this bug related to the browser.tabs.remote.useHTTPResponseProcessSelection? Could be 'Tabbed Browser' the right component? Is this issue related to the bug 675539?

Component: Untriaged → Tabbed Browser
Component: Tabbed Browser → DOM: Content Processes
Product: Firefox → Core

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Blocks: 1562223
Flags: needinfo?(jmathies)
Priority: -- → P3
Fission Milestone: --- → M5

This issue is still occuring for me on 69.0.1 on macOS 10.14.6, regardless of setting of the about:config flag mentioned above. It does not appear to be a local firewall issue or anything because it works just fine for me if I do it in Safari instead.

issue also occuring for me on Firefox 70.0 on Linux Debian/Ubuntu
setting browser.tabs.remote.useHTTPResponseProcessSelection doesn't change anything
the same url started works with falcon and chrome via "Open With" add-on

Can you please confirm if this is still reproducible with latest nightly? It should have browser.tabs.documentchannel set to true by default.

Flags: needinfo?(robin)

Fixed, thanks!

Flags: needinfo?(robin)
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.