Use of relative paths in tabs.create() versus window.open()

Add-ons Development
#1

I’m working on an extension in which the user may open a local html file and work offline.

Once the user opens the local html file in the browser, I’d like to enable the user to open a different local html file (of the same origin) in a new tab through a button click only. The only purpose for this is to provide a web page for a second indexedDB database.

Since the second local html file is always of the same origin and in a set location, using window.open() and a relative path accomplishes the task when the user preferences are set to open a link in a new tab rather than a window.

However, tabs.create() appears to treat relative paths as relative to the extension only and not the location of the current page, regardless of whether the relative path begins with a “/” or not.

Is there a way to use tabs.create() or some other method to open a local html file using a relative path to an already loaded local html file of the same origin?

I understand that an absolute path to a local file cannot be opened through tabs.create() and why. I’d just like to accomplish what window.open() already does but in a tab always.

Thank you.

#2

As far as I could find, the term same origin isn’t even specified for file system URLs. Loading anything more than plain HTML files directly from the disk is therefore inconsistent and poorly documented. Just avoid it, like everybody else does.

To answer your question regarding relative URL resolution, try this:

resolvedUrl = new URL(relativeUrl, previousAbsoluteUrl).href;
#3

Thank you for responding to my question and for providing a possible solution. I will try it out shortly.

As an aside, in regards to your comments about same origin and loading anything more than plain html files from the local disk, I have a couple brief observations to share.

It appears that at least some groups use local html files for specific purposes with success. In part, I got the idea for what I’ve been building from viewing CDs of medical diagnostic images (MRI and CT scans) provided by a diagnostic imaging center. Because there isn’t currently a set standard that makes all images viewable across the many different medical softwares, the imaging centers provide on the CD a small local web site of a few pages within which the diagnostic images can be viewed in most browsers, all offline. The scripts run, and it serves its purpose well. Of course, it’s just to make the images viewable for a cursory review and a medical software is needed for detailed measurements, etcetera.

I don’t remember if I ever read anything specific to local html files regarding same origin but in working with them I noticed that a local html file can be opened in an iFrame within another local html file and its scripts will run so long as it is at either the same level or below the parent page in the file structure. If it is above the parent html file, then it will be displayed but the scripts won’t run. That is for Firefox and Chrome.

Thanks again.

#4

Yes, a general rule that is implemented in Chrome and Firefox is that a html file can load stuff from the same directory and sub directories without SOP restrictions, while anything from parent and sibling directories is considered cross-origin. But the weird thing is that this is an asymmetrical relation. AFAIK all other SOP stuff is symmetrical (i.e. if A can access B, B can access A).
Since one of this is specified, You are always left guessing what actually works.

#5

I tried the new URL() method and, unfortunately, it doesn’t work because the resolvedUrl is still a priveleged URL and doesn’t get treated as a relative URL as in window.open(), and tabs.create() fails to execute.

The tabs.duplicate() method will open a new tab with the URL of the same local html page without any problem. The window.open() method, with a relative path as its parameter, will open a new tab/window relative to the window.location.href even for a local html page. If tabs.create() is provided a relative path, the browser makes it relative to the extension rather than the window.location.href.

I tried using the base tag to change the base href but that appears to change only for elements within the page and not methods.

It appears that tabs.create() and tabs.update() are more strict, relative to opening local html pages, than are tabs.duplicate() and window.open(). Unless there is a way to set the base used in tabs.create() to the window.location.href rather than the extension location, it doesn’t appear that tabs.create() can be used to open a local html page even with a relative path, as can be done with window.open().

I got around the problem by duplicating the current tab and then injecting a script that uses window.open() with the desired relative path to the window.location.href and target = ‘_self’.

ADDED LATER:

I forgot to include a link to one piece of MDN documentation concerning the same-origin policy for local html files that I came across awhile back and which is also consistent with the comments of NiklasG. https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs

I’d like to understand how this policy relates to accessing indexedDB databases in local html pages, such as whether or not each local html page get its own database for which access is determined under this same same-origin policy. My interest is that I’d like to divide the data generated by the extension between two separate indexedDB databases by using two local pages (not the extension’s database) and allow each page to read/write to the other page’s database, if possible. This will be controlled through the extension code but this really isn’t an extension question; so, I won’t start a new topic here. But if you could point me to some good information, thank you.

1 Like