# Firefox 68: local files now treated as cross-origin (1558299)

**URL:** <https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493>\
**Category:** Firefox Development\
**Created:** [July 12, 2019, 6:47pm UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493 "2019-07-12T18:47:07Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_Bushakra](https://avatars.discourse-cdn.com/v4/letter/j/3ec8ea/32.png) [@John\_Bushakra](https://discourse.mozilla.org/u/John_Bushakra)\
**Post date:** [July 12, 2019, 6:47pm UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493/1 "2019-07-12T18:47:07Z")

</div>

Where can I get more information about the implementation of this change in FireFox 68? The specific bug ( [Bug 1558299](https://bugzilla.mozilla.org/show_bug.cgi?id=1558299)) is apparently marked as “secure”, and I can’t view it.

I’m asking because apparently this change broke our HTML help system when the files are open through the file system. We have property accessors and function calls that must be made synchronously, so the postMessage() function won’t work in this case.

Any help/advice is appreciated.  
-J

---

<div class="post-metadata">

**Author:** ![evilpie](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/evilpie/32/30580_2.png) [@evilpie](https://discourse.mozilla.org/u/evilpie)\
**Post date:** [July 12, 2019, 7:18pm UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493/2 "2019-07-12T19:18:12Z")

</div>

[Bug 1500453](https://bugzilla.mozilla.org/show_bug.cgi?id=1500453) is public and has some information.

You can disable this new restriction with `privacy.file_unique_origin` in about:config.

---

<div class="post-metadata">

**Author:** ![John\_Bushakra](https://avatars.discourse-cdn.com/v4/letter/j/3ec8ea/32.png) [@John\_Bushakra](https://discourse.mozilla.org/u/John_Bushakra)\
**Post date:** [July 12, 2019, 7:27pm UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493/3 "2019-07-12T19:27:25Z")

</div>

Hi Tom, thanks for the link to 1500453.

I know about the about:config workaround, however, we have many _many_ installations at customer sites. Some do host the docs internally (and so have no problems), but others choose to access from the file system. We also do context-sensitive help calls from applications, and these open topics from the file system.

---

<div class="post-metadata">

**Author:** ![bzbarsky](https://avatars.discourse-cdn.com/v4/letter/b/c37758/32.png) [@bzbarsky](https://discourse.mozilla.org/u/bzbarsky)\
**Post date:** [July 13, 2019, 3:06am UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493/4 "2019-07-13T03:06:23Z")

</div>

John, does this the HTML help system work in other browsers? Or was it Firefox-only?

In general, help systems was the main known case that was expected to be impacted by the change, but there wasn’t really a way to keep that sort of use case working with cross-file scripting while fixing the problem being reported…

---

<div class="post-metadata">

**Author:** ![John\_Bushakra](https://avatars.discourse-cdn.com/v4/letter/j/3ec8ea/32.png) [@John\_Bushakra](https://discourse.mozilla.org/u/John_Bushakra)\
**Post date:** [July 15, 2019, 2:24pm UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493/5 "2019-07-15T14:24:38Z")

</div>

Hi Boris,

I didn’t realize that we already had checks for file system access for Chrome. Our help system works in Chrome, but with slightly reduced  
functionality.

Since cross-origin behavior is now virtually the same across browsers, we updated our checks to disregard the browser and look only to  
see if topics are being accessed directly from the file system. So, things are working consistently, albeit with reduced (but livable) functionality.

Thanks again to all for the help!

John

---

<div class="post-metadata">

**Author:** ![bzbarsky](https://avatars.discourse-cdn.com/v4/letter/b/c37758/32.png) [@bzbarsky](https://discourse.mozilla.org/u/bzbarsky)\
**Post date:** [July 15, 2019, 2:43pm UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493/6 "2019-07-15T14:43:13Z")

</div>

John,

Great, thank you for checking that!

And yes, at this point the cross-origin behavior for file:// should generally match across browsers…

---

<div class="post-metadata">

**Author:** ![mcdow](https://avatars.discourse-cdn.com/v4/letter/m/0ea827/32.png) [@mcdow](https://discourse.mozilla.org/u/mcdow)\
**Post date:** [July 15, 2019, 5:46pm UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493/7 "2019-07-15T17:46:34Z")

</div>

Guys,

With FireFox v68 update, origin behavior is most certainly not the same across all major browser vendors. I believe the v68 update is broken in comparison to the other vendors. Specifically, here is Mozilla’s definition for ‘file:’ origin.

[https://developer.mozilla.org/en-US/docs/Archive/Misc\_top\_level/Same-origin\_policy\_for\_file:\_URIs](https://developer.mozilla.org/en-US/docs/Archive/Misc_top_level/Same-origin_policy_for_file:_URIs)

With v68, essentially every file has its own “origin”, making local file resource loading inoperable.

Also, this is does not appear to be a javascript or postMessage() issue. This is a local resource loading issue.

Currently, this impacts many local help systems being used today, with result being limited functionality on FireFox, while working on: Safari MacOS/iOS, Google Chrome, Microsoft Edge, and Microsoft IE11. Please advise.

Thank you.

---

<div class="post-metadata">

**Author:** ![John\_Bushakra](https://avatars.discourse-cdn.com/v4/letter/j/3ec8ea/32.png) [@John\_Bushakra](https://discourse.mozilla.org/u/John_Bushakra)\
**Post date:** [July 16, 2019, 5:07pm UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493/8 "2019-07-16T17:07:29Z")

</div>

On the topic of resource loading issues, another security fix in version 68 stops access to cameras and microphones in non-secure contexts  
such as http, and, presumably, file://.

However, it looks like “cameras and microphones” also includes “other media devices”, as described at this link (scroll to the DOM APIs  
section):

[https://hacks.mozilla.org/2019/07/firefox-68-bigints-contrast-checks-and-the-quantumbar/](https://hacks.mozilla.org/2019/07/firefox-68-bigints-contrast-checks-and-the-quantumbar/)

And “other media devices” apparently includes video playback.

We are now seeing an issue playing instructional videos (mp4) from an tag. When accessing from both file:// and from http://,  
we get a blank page, with no content, and no errors in the console. When accessing from https://, the video plays.

I have tried giving the site permissions to access media devices, with no success. Even if I can get http working, I assume file:// would  
still be broken.

Have I diagnosed this properly, i.e. is this video issue related to the “cameras, microphones, **and other media devices** ” as described  
by Dan Callahan in the link above?

Thanks,

John

---

<div class="post-metadata">

**Author:** ![jscher2000](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/jscher2000/32/28202_2.png) [@jscher2000](https://discourse.mozilla.org/u/jscher2000)\
**Post date:** [July 17, 2019, 3:05pm UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493/9 "2019-07-17T15:05:47Z")

</div>

> [@John\_Bushakra](#):
>
> We are now seeing an issue playing instructional videos (mp4) from an tag. When accessing from both file:// and from http://,  
> we get a blank page, with no content, and no errors in the console. When accessing from https://, the video plays.

Video playback doesn’t involve the same privacy concerns as recording, so there’s no obvious reason for Firefox to treat them the same way.

I don’t notice a problem in a simple video tag where the source video is in the same directory (locally accessed on file://):

```auto
<video controls="controls" preload="none" width="560" height="320">
  <source src="big_buck_bunny.mp4" type="video/mp4">
</video>

```

That’s static HTML, not scripted, if that makes a difference.

---

<div class="post-metadata">

**Author:** ![John\_Bushakra](https://avatars.discourse-cdn.com/v4/letter/j/3ec8ea/32.png) [@John\_Bushakra](https://discourse.mozilla.org/u/John_Bushakra)\
**Post date:** [July 17, 2019, 3:31pm UTC](https://discourse.mozilla.org/t/firefox-68-local-files-now-treated-as-cross-origin-1558299/42493/10 "2019-07-17T15:31:54Z")

</div>

Okay, looks like this one is related to using as opposed to

Replacing object with video works. We have videos shared between multiple books, so it works even though the videos aren’t in the same  
directory as the topic file. Confirmed it does work with both plain http and file:// as well.

As for with plain http and file system, that definitely was working in FireFox in versions prior to 68, and it does still work  
in Chrome.

Thanks,

John