Where can I get more information about the implementation of this change in FireFox 68? The specific bug ( Bug 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
Bug 1500453 is public and has some information.
You can disable this new restriction with privacy.file_unique_origin in about:config.
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.
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…
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
John,
Great, thank you for checking that!
And yes, at this point the cross-origin behavior for file:// should generally match across browsers…
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.
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.
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/
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
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://):
<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.
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