Firefox 23: The Load of a local java applet (*jar) fails silently

VERIFIED FIXED in Firefox 24

Status

()

defect
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: trackfirefox, Assigned: johns)

Tracking

({regression, testcase})

23 Branch
mozilla26
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox22 unaffected, firefox23 wontfix, firefox24+ verified, firefox25+ verified, firefox26+ verified, firefox-esr17 unaffected)

Details

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130730113002

Steps to reproduce:

A local web application intended to be an off-line DVD, uses a local java applet.
Up to version 22 it worked fine.

The html is:
<applet width="960" height="425" archive="jclic.jar" codebase="../jclic/" code="JClicApplet">
<param value="application/x-java-applet;version=1.4" name="type">
<param value="false" name="scriptable">
<param value="cap1-03J.jclic.zip" name="activityPack">
</applet>

Trying to set codebase to a full path: "/...../jclic"
and a full url: "file:///...../jclic" 

both still fail.

The error happens both in Mac OS and Windows with Version 23


Actual results:

The applet is not loaded.
No error is shown.
Java v is not invoked.


Expected results:

The applet loaded.
We need a testcase as an attachment and eventually a regression range using mozregression (see https://github.com/mozilla/mozregression).
Component: General → Plug-ins
OS: Mac OS X → All
Hardware: x86 → All

Updated

6 years ago
Flags: needinfo?(trackfirefox)
(Reporter)

Comment 2

6 years ago
A Test case for the problem.
Unzip and open ./html/index.html.
The applet being loaded is in ./jclic/jclic.jar
Flags: needinfo?(trackfirefox)
(Reporter)

Comment 3

6 years ago
Hi!

Thanks Scoobidiver!

About mozregression, I'm affraid I'm not being able to correctly install (and use).
I'm not familiar with Mozilla development workflows.

What I can tell is:
It works correctly with release 22.0, Mac OS X and Windows
It fails with release 23.0 (today August 7, 2013), both Mac OS X and Windows.

Many thanks in advance.
Dino
The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b48e06621dc9&tochange=dcbbfcdf7bb4
It's likely a regression from bug 888834 or bug 406541 .
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

6 years ago
I believe that this is by design. Our same-origin policy for sites loaded from file: is that they may only access files in their directory and subdirectories. The codebase="../jclic/" indicates that this is trying to load Java from a parent directory. That is specifically what we were fixing.

See https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs for background. If you flip the security.fileuri.strict_origin_policy pref to `false`, does that cause your Java to load? If so I expect that this is WONTFIX, but I'll let johns double-check me here.
Assignee: nobody → jschoenick
(Reporter)

Comment 6

6 years ago
(Reporter)

Comment 7

6 years ago
Hi Benjamin!

Thanks for your work!

First, I confirm that with security.fileuri.strict_origin_policy pref to `false`
it works.

We don't like the final user has to change the settings, so
we can rearrange to find the java in a subdirectory.
But we have prepared a second test case with this approach
(java in a subdirectory and security.fileuri.strict_origin_policy = true).
No success:
It does not load the java.

I have attached this second test case (case2.zip).

Please confirm us if you reproduce the same behaviour.

Many thanks again!

Dino.
The regression range for the second testcase is still the same.
needinfo on John to help with comment #5 and understand if this is a valid bug ?
Flags: needinfo?(jschoenick)
(Assignee)

Comment 10

6 years ago
The case where codebases outside of the current directory are blocked is intentional -- however, the case where subdirectories do not work properly is not :(
Status: NEW → ASSIGNED
Flags: needinfo?(jschoenick)
(Assignee)

Updated

6 years ago
(Assignee)

Comment 11

6 years ago
Sigh. Fail. Most of the code in 406541 was to split out NS_RelaxStrictFileOrigin to allow adding the aAllowDirectoryTarget parameter. If only the added security check actually called it...

I added this to the tests for bug 406541, which haven't landed yet.
Attachment #787153 - Flags: review?(benjamin)
(Assignee)

Comment 12

6 years ago
Bonus edge case found while looking at this - the strict file origin logic might fail if the target of an operation is the parent directory of the given file, and aAllowDirectoryTarget = true. (with allowDirectoryTarget a file should be able to target its own directory)
Attachment #787154 - Flags: review?(bzbarsky)
Comment on attachment 787154 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source

Can you assert that if NS_SUCCEEDED(rv) && allowed for the Equals() call (basically an else for the if you have there) then aAllowDirectoryTarget is true?

r=me with that
Attachment #787154 - Flags: review?(bzbarsky) → review+
(Assignee)

Updated

6 years ago
Duplicate of this bug: 904033

Updated

6 years ago
Attachment #787153 - Flags: review?(benjamin) → review+
(Assignee)

Comment 16

6 years ago
Comment on attachment 793159 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source. r=bz

addressed review comments
Attachment #793159 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/8258b8c636a9
https://hg.mozilla.org/mozilla-central/rev/c4007e82f13b
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla26

Comment 19

6 years ago
I don't know what the procedure for backports is on mozilla, but could this be backported to at least FF 24, since it is going to be an ESR release?
Flags: needinfo?(jschoenick)
(Assignee)

Comment 20

6 years ago
Comment on attachment 787153 [details] [diff] [review]
Actually use the optional parameter added explicitly for this purpose

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
406541

User impact if declined:
Local (file://) pages that use Java don't work properly in some cases

Testing completed (on m-c, etc.):
On m-c

Risk to taking this patch (and alternatives if risky):
Very low, these changes only affect java applets on file URIs.

String or IDL/UUID changes made by this patch:
None
Attachment #787153 - Flags: approval-mozilla-beta?
Attachment #787153 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 21

6 years ago
Comment on attachment 793159 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source. r=bz

see comment 20
Attachment #793159 - Flags: approval-mozilla-beta?
Attachment #793159 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 22

6 years ago
Tests for this will land with the 406541 tests
Flags: needinfo?(jschoenick)
Attachment #787153 - Flags: approval-mozilla-beta?
Attachment #787153 - Flags: approval-mozilla-beta+
Attachment #787153 - Flags: approval-mozilla-aurora?
Attachment #787153 - Flags: approval-mozilla-aurora+
Attachment #793159 - Flags: approval-mozilla-beta?
Attachment #793159 - Flags: approval-mozilla-beta+
Attachment #793159 - Flags: approval-mozilla-aurora?
Attachment #793159 - Flags: approval-mozilla-aurora+
Keywords: verifyme
(Reporter)

Comment 24

6 years ago
Hi All!

Just to confirm...

With Nightly 26.0a1 (2013-08-23), my testcase works correctly.

I will check with aurora and beta.

Thanks!!

Comment 25

6 years ago
Verified as fixed on Firefox 24 beta 6 (20130826142034) - Windows 7 64bit, Ubuntu 13.04 32bit and Mac OSX 10.7.5.

The applet in the first testcase doesn't load - as specified by design.
The applet in the second testcase loads fine.
QA Contact: ioana.budnar

Comment 26

6 years ago
Also verified on Firefox 25:
Mac OS X 10.8.4 - 20130912004004
Ubuntu 13.04 - 20130911004006
Windows 7 - 20130912004004
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0

Verified as fixed on latest Aurora 26.0a2 (buildID: 20131010004002).
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.