The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in Firefox 24

Status

()

Core
Plug-ins
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: trackfirefox, Assigned: johns)

Tracking

({regression, testcase})

23 Branch
mozilla26
regression, testcase
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

4 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.

Comment 1

4 years ago
We need a testcase as an attachment and eventually a regression range using mozregression (see https://github.com/mozilla/mozregression).
Component: General → Plug-ins
Keywords: regression, regressionwindow-wanted, testcase-wanted
OS: Mac OS X → All
Hardware: x86 → All

Updated

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

Comment 2

4 years ago
Created attachment 786840 [details]
testcase. unzip and open ./html/index.html

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

4 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

Comment 4

4 years ago
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
Keywords: regressionwindow-wanted, testcase-wanted → testcase

Updated

4 years ago
status-firefox23: --- → affected
tracking-firefox24: --- → ?
tracking-firefox25: --- → ?
tracking-firefox26: --- → ?
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

4 years ago
Created attachment 786945 [details]
test case 2. java in a subdirectory
(Reporter)

Comment 7

4 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.

Comment 8

4 years ago
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

4 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

4 years ago
Blocks: 406541
(Assignee)

Updated

4 years ago
status-firefox24: --- → affected
status-firefox25: --- → affected
status-firefox26: --- → affected
status-firefox-esr17: --- → unaffected
(Assignee)

Comment 11

4 years ago
Created attachment 787153 [details] [diff] [review]
Actually use the optional parameter added explicitly for this purpose

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

4 years ago
Created attachment 787154 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source

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+

Updated

4 years ago
tracking-firefox24: ? → +
tracking-firefox25: ? → +
tracking-firefox26: ? → +
(Assignee)

Updated

4 years ago
Duplicate of this bug: 904033
Attachment #787153 - Flags: review?(benjamin) → review+
(Assignee)

Comment 15

4 years ago
Created attachment 793159 [details] [diff] [review]
Strict file origin policy - handle case where the target is the parent directory of the source. r=bz
Attachment #787154 - Attachment is obsolete: true
(Assignee)

Comment 16

4 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+
(Assignee)

Comment 17

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/c4007e82f13b
https://hg.mozilla.org/integration/mozilla-inbound/rev/8258b8c636a9
https://hg.mozilla.org/mozilla-central/rev/8258b8c636a9
https://hg.mozilla.org/mozilla-central/rev/c4007e82f13b
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox26: affected → fixed
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla26

Comment 19

4 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

4 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

4 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

4 years ago
Tests for this will land with the 406541 tests
status-firefox22: --- → unaffected
status-firefox23: affected → wontfix
Flags: needinfo?(jschoenick)

Updated

4 years ago
Attachment #787153 - Flags: approval-mozilla-beta?
Attachment #787153 - Flags: approval-mozilla-beta+
Attachment #787153 - Flags: approval-mozilla-aurora?
Attachment #787153 - Flags: approval-mozilla-aurora+

Updated

4 years ago
Attachment #793159 - Flags: approval-mozilla-beta?
Attachment #793159 - Flags: approval-mozilla-beta+
Attachment #793159 - Flags: approval-mozilla-aurora?
Attachment #793159 - Flags: approval-mozilla-aurora+

Updated

4 years ago
Keywords: verifyme
https://hg.mozilla.org/releases/mozilla-aurora/rev/f6a238e848d3
https://hg.mozilla.org/releases/mozilla-aurora/rev/1554a8d1eb6e

https://hg.mozilla.org/releases/mozilla-beta/rev/19d4d4a86051
https://hg.mozilla.org/releases/mozilla-beta/rev/243498415456
status-firefox24: affected → fixed
status-firefox25: affected → fixed
(Reporter)

Comment 24

4 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

4 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.
status-firefox24: fixed → verified
QA Contact: ioana.budnar

Comment 26

4 years ago
Also verified on Firefox 25:
Mac OS X 10.8.4 - 20130912004004
Ubuntu 13.04 - 20130911004006
Windows 7 - 20130912004004
status-firefox25: fixed → verified
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
status-firefox26: fixed → verified
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.