Open Bug 1945395 Opened 1 year ago Updated 3 months ago

Opening an .opml file enters infinite loop of opening tabs

Categories

(Firefox :: File Handling, defect)

Desktop
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: mhdvd, Unassigned, NeedInfo)

References

Details

(Whiteboard: [qa-not-actionable])

Attachments

(1 file)

404 bytes, text/x-opml+xml
Details
Attached file feeds.opml

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

Open the attached .opml file with firefox.
I run firefox on Debian 12 under firejail sandbox

commands:
apt install firejail
firejail firefox

I am using default firejail profile for firefox, which in principle restricts user's access to only the Download folder, among other things. Apparently, using firejail disables default sandboxing and uses it instead.

My firefox verision according to the settings page is:
115.12.0esr

Actual results:

https://vimeo.com/1052823278/548425986a
https://vimeo.com/1052823294/9d451adfc1

When the attached file is opened, firefox enters a loop constantly creating a new tab trying to open the file.

Expected results:

I am not sure, but not this.

Also note, after closing firefox and opening it again, it continues in the loop, presumably because of session restore.

If I do a middle mouse click (center wheel) on a bookmark from the bar, the loop stops, and aI can right-click->close all tabs to the left.
Normal left-click on a bookmark does not open it when in the loop.

I can reproduce locally by simply attempting to open the troubled file again.

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Tabbed Browser

(In reply to Mihai from comment #1)

Also note, after closing firefox and opening it again, it continues in the loop, presumably because of session restore.

If I do a middle mouse click (center wheel) on a bookmark from the bar, the loop stops, and aI can right-click->close all tabs to the left.
Normal left-click on a bookmark does not open it when in the loop.

I can reproduce locally by simply attempting to open the troubled file again.

update: if I left click many times in a row on a bookmark it does stop the loop.

It sounds like Bug 1842542, if you set Firefox as default handler in the system, but Firefox doesn't know how to handle that format, then it will hand it to the OS that will pass it back to Firefox, and so on.
Is Firefox set as the default handler of .opml in your system?

Component: Tabbed Browser → File Handling
Flags: needinfo?(mhdvd)
See Also: → 1842542

Also, if you (temporarily) disable firejail and run Firefox outside of it, does that make any difference to the outcome?

(In reply to Marco Bonardo [:mak] from comment #4)

It sounds like Bug 1842542, if you set Firefox as default handler in the system, but Firefox doesn't know how to handle that format, then it will hand it to the OS that will pass it back to Firefox, and so on.

Is Firefox set as the default handler of .opml in your system?

$ xdg-mime query filetype feeds.opml
$ xdg-mime query default text/x-opml+xml
(empty output)

$ xdg-mime query default text/html
firefox.desktop

Seems like it isn't.
However, if I do
$ xdg-open test.opml
Firefox opens. Using firejail. Bug reproduces.

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

Also, if you (temporarily) disable firejail and run Firefox outside of it, does that make any difference to the outcome?

Flags: needinfo?(mhdvd)

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

Also, if you (temporarily) disable firejail and run Firefox outside of it, does that make any difference to the outcome?

I tried. No changes in behavior. Bug reproduces. Both when opening the file by accesing file:///path/to/feeds.opml and when using xdg-open.

note that I do have firefox set as the default browser in my system, so maybe that's why these files are open automatically regardless of the xdg-open / xdg-mime configuration, and maybe that's how the loop is entered (?)

Thanks for trying this. My Linux VM is horked atm, but I think there are two problems (similar to the linked bug) - one is determining the mimetype and default handler of the file, the other is the loop that happens once we get passed the file by the OS. I'm guessing the first problem is the same as in bug 1885804 - we misinterpret the result of asking GIO for a mimetype - I've passed that to people who understand the relevant APIs and what might be sensible next steps. As for the loop, there is already code meant to prevent this by comparing what the OS says is going to handle the file and our own binary path. I would still like to understand why that doesn't seem to be working, so it would be helpful if you could check a few things relating to this here:

If you:

  1. open the browser settings/preferences
  2. open the devtools console there
  3. run:
Cc["@mozilla.org/mime;1"].getService(Ci.nsIMIMEService).getFromTypeAndExtension("text/html", "html").defaultExecutable?.path

and

Cc["@mozilla.org/mime;1"].getService(Ci.nsIMIMEService).getFromTypeAndExtension("text/x-opml+xml", "opml").defaultExecutable?.path

and

Cc["@mozilla.org/mime;1"].getService(Ci.nsIMIMEService).getFromTypeAndExtension("application/x-extension-opml, "opml").defaultExecutable?.path

Do they all produce the same path?

And, is that path the same as:

Services.dirsvc.get("XREExeF", Ci.nsIFile)?.path
Flags: needinfo?(mhdvd)
See Also: → 1885804

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

Thanks for trying this. My Linux VM is horked atm, but I think there are two problems (similar to the linked bug) - one is determining the mimetype and default handler of the file, the other is the loop that happens once we get passed the file by the OS. I'm guessing the first problem is the same as in bug 1885804 - we misinterpret the result of asking GIO for a mimetype - I've passed that to people who understand the relevant APIs and what might be sensible next steps. As for the loop, there is already code meant to prevent this by comparing what the OS says is going to handle the file and our own binary path. I would still like to understand why that doesn't seem to be working, so it would be helpful if you could check a few things relating to this here:

If you:

  1. open the browser settings/preferences
  2. open the devtools console there
  3. run:
Cc["@mozilla.org/mime;1"].getService(Ci.nsIMIMEService).getFromTypeAndExtension("text/html", "html").defaultExecutable?.path

and

Cc["@mozilla.org/mime;1"].getService(Ci.nsIMIMEService).getFromTypeAndExtension("text/x-opml+xml", "opml").defaultExecutable?.path

and

Cc["@mozilla.org/mime;1"].getService(Ci.nsIMIMEService).getFromTypeAndExtension("application/x-extension-opml, "opml").defaultExecutable?.path

Do they all produce the same path?

And, is that path the same as:

Services.dirsvc.get("XREExeF", Ci.nsIFile)?.path

HI, I followed instructions here https://firefox-source-docs.mozilla.org/devtools-user/browser_console/index.html
and pressed Ctr+Shift+J to open this:
https://files.catbox.moe/w177qz.png

I cannot input js :) in browser settings I didn't find anything similar.

Flags: needinfo?(mhdvd)

(In reply to Mihai from comment #10)

HI, I followed instructions here https://firefox-source-docs.mozilla.org/devtools-user/browser_console/index.html
and pressed Ctr+Shift+J to open this:
https://files.catbox.moe/w177qz.png

I cannot input js :) in browser settings I didn't find anything similar.

Did you also do this bit:

NB: The Browser Console command line (to execute JavaScript expressions) is disabled by default. To enable it set the devtools.chrome.enabled preference to true in about:config, or set the “Enable browser chrome and add-on debugging toolboxes” (Firefox 40 and later) option in the developer tool settings.

(that pref is what controls the input box appearing in the browser console)

Flags: needinfo?(mhdvd)

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

(In reply to Mihai from comment #10)

HI, I followed instructions here https://firefox-source-docs.mozilla.org/devtools-user/browser_console/index.html
and pressed Ctr+Shift+J to open this:
https://files.catbox.moe/w177qz.png

I cannot input js :) in browser settings I didn't find anything similar.

Did you also do this bit:

NB: The Browser Console command line (to execute JavaScript expressions) is disabled by default. To enable it set the devtools.chrome.enabled preference to true in about:config, or set the “Enable browser chrome and add-on debugging toolboxes” (Firefox 40 and later) option in the developer tool settings.

(that pref is what controls the input box appearing in the browser console)

https://files.catbox.moe/lmb261.png

Not sure if I did this right :)

Flags: needinfo?(mhdvd)

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Mihai from comment #12)

Sorry for the slow response - got some health stuff going on.

(In reply to :Gijs (he/him) from comment #11)
https://files.catbox.moe/lmb261.png

Not sure if I did this right :)

You did everything right but apparently in the Linux case the API I was hoping to use to determine what is going on is unsupported. I need to dig into it a bit more to work out if that on its own explains why the redirect loop protection bit isn't working, if I can repro, and/or what we can do about that.

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

(In reply to Mihai from comment #12)

Sorry for the slow response - got some health stuff going on.

(In reply to :Gijs (he/him) from comment #11)
https://files.catbox.moe/lmb261.png

Not sure if I did this right :)

You did everything right but apparently in the Linux case the API I was hoping to use to determine what is going on is unsupported. I need to dig into it a bit more to work out if that on its own explains why the redirect loop protection bit isn't working, if I can repro, and/or what we can do about that.

Thanks for your time, let me know if there's anything else you want me to try, I'll stay tuned.

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

(In reply to Mihai from comment #12)

Sorry for the slow response - got some health stuff going on.

No worries, take care.

Hi @Mihai, are you still able to reproduce this issue in our latest builds? I tried to reproduce it on an Ubuntu 24 with our latest Nightly build but the file simply opens and shows the code for it.
If you are willing to try here is our latest Nightly build: https://www.mozilla.org/en-US/firefox/channel/desktop/

Flags: needinfo?(mhdvd)
OS: Unspecified → Linux
QA Contact: rdoghi
Hardware: Unspecified → Desktop

(In reply to Rares Doghi, Desktop QA from comment #17)

Hi @Mihai, are you still able to reproduce this issue in our latest builds? I tried to reproduce it on an Ubuntu 24 with our latest Nightly build but the file simply opens and shows the code for it.
If you are willing to try here is our latest Nightly build: https://www.mozilla.org/en-US/firefox/channel/desktop/

It depends on the OS settings (so if you can't repro your OS is probably providing better mimetype information that the reporter's), but we haven't changed anything in Firefox, so unless the OS has changed this will still reproduce.

Flags: needinfo?(mhdvd)
Whiteboard: [qa-not-actionable]
See Also: → 1996035
See Also: → 1991596
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: