Closed Bug 508369 Opened 16 years ago Closed 14 years ago

mochitest-plain: intermittent "test_bug369814.html | iframes.html loaded from view-source jar type (or from non-jar type), pref disabled: should block a suspicious JAR load"

Categories

(Core :: Networking: JAR, defect, P1)

Product:
Core
Component:
Networking: JAR
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla6
Tracking Flags:
Tracking Status
blocking2.0 --- .x+

People

(Reporter: sgautherie, Assigned: bzbarsky)

References

(
URL
)

Details

(Keywords: intermittent-failure, Whiteboard: [softblocker])

Attachments

(4 files)

fix test [Checked in: Comment 16 & 67]
953 bytes, patch
bzbarsky
: review+
Details | Diff | Splinter Review
part 1. Move the detection of loads inheriting a principal later in InternalLoad so that we catch ones that pass in a non-null owner directly [Checked in: Comment 84]
5.40 KB, patch
jst
: review+
Details | Diff | Splinter Review
part 2. Change the test to catch the error fixed in part 1 in the future. This is just removing an extra .parent from the scripts in anchors.html inside the zip file [Checked in: Comment 84]
1.40 KB, patch
jst
: review+
Details | Diff | Splinter Review
part 3. Stop using timeouts in the test. zip file change is just a change to replace top.poke() with parent.poke() so that the refresh test will be useful in the harness too [Checked in: Comment 84]
5.34 KB, patch
ehsan.akhgari
: review+
Details | Diff | Splinter Review
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1249411693.1249420049.27935.gz WINNT 5.2 comm-1.9.1 unit test on 2009/08/04 11:48:13 ... | iframes.html loaded from view-source jar type, pref disabled: should block a suspicious JAR load.
Blocks: 438871
Whiteboard: [orange]
(In reply to comment #0) cb-seamonkey-win32-01 *** http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1249720613.1249729382.14590.gz WINNT 5.2 comm-1.9.1 unit test on 2009/08/08 01:36:53 cb-seamonkey-win32-01
Blocks: SmTestFail
Summary: mochitest-plain: test_bug369814.html intermittently fails → [SeaMonkey? Windows?] mochitest-plain: test_bug369814.html intermittently fails
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1251188124.1251199506.17032.gz WINNT 5.2 comm-1.9.1 unit test on 2009/08/25 01:15:24 Building on: cb-seamonkey-win32-01 { ... | iframes.html loaded from view-source jar type, pref disabled: should block a suspicious JAR load. ... | iframes.html loaded from view-source jar type, pref enabled: should block a suspicious JAR load. }
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1251960134.1251970892.17799.gz WINNT 5.2 comm-1.9.1 unit test on 2009/09/02 23:42:14 cb-seamonkey-win32-01 { ... | iframes.html loaded from view-source jar type, pref disabled: should block a suspicious JAR load. } NB: Always this VM, but truly intermittent.
Summary: [SeaMonkey? Windows?] mochitest-plain: test_bug369814.html intermittently fails → [SeaMonkey, cb-seamonkey-win32-01] mochitest-plain: test_bug369814.html intermittently fails
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1254956006.1254964770.22421.gz WINNT 5.2 comm-1.9.1 unit test on 2009/10/07 15:53:26 cb-seamonkey-win32-01
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256025114.1256028146.22384.gz OS X 10.5.2 mozilla-central test mochitests on 2009/10/20 00:51:54 44603 ERROR TEST-UNEXPECTED-FAIL | /tests/docshell/test/test_bug369814.html | iframes.html loaded from view-source jar type, pref disabled: should block a suspicious JAR load.
(In reply to comment #5) > OS X 10.5.2 mozilla-central test mochitests on 2009/10/20 00:51:54 Building on: moz2-darwin9-slave07
No longer blocks: SmTestFail
OS: Windows Server 2003 → All
Summary: [SeaMonkey, cb-seamonkey-win32-01] mochitest-plain: test_bug369814.html intermittently fails → mochitest-plain: intermittent "test_bug369814.html | iframes.html loaded from view-source jar type, pref disabled: should block a suspicious JAR load"
Version: 1.9.1 Branch → Trunk
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256487340.1256488117.28513.gz WINNT 5.2 mozilla-central test debug mochitests-2/5 on 2009/10/25 09:15:40
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1256766948.1256769908.3340.gz WINNT 5.2 mozilla-central test debug mochitests-2/5 on 2009/10/28 14:55:48
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1258658283.1258661353.12351.gz WINNT 5.2 mozilla-central debug test mochitests-2/5 on 2009/11/19 11:18:03 "s: moz2-win32-slave12"
I've got this one in a record/replay log.
Something's wrong with the test: http://mxr.mozilla.org/mozilla-central/source/docshell/test/test_bug369814.html?force=1#152 { "name" : "iframes.html loaded from view-source jar type, pref disabled", "url" : "jar:view-source:http://localhost:8888/tests/docshell/test/bug369814.jar!/iframes.html", "pref" : true, "pref" should be false here, shouldn't it?
Although since we have exactly the same test in the next test, I'm guessing there is still a bug here even once the test is fixed.
This doesn't fix the random orange, I think, but still worth fixing...
Attachment #418280 - Flags: review?(bzbarsky)
Attachment #418280 - Flags: review?(bzbarsky) → review+
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1262491404.1262492129.7184.gz WINNT 5.2 mozilla-central opt test mochitests-2/5 on 2010/01/02 20:03:24 s: win32-slave10
Whiteboard: [orange] → [orange][needs landing]
Keywords: checkin-needed
Fixed the test: http://hg.mozilla.org/mozilla-central/rev/f62942e7f4e2 I suspect the orange must still happen. Let's wait for reports to come in.
Whiteboard: [orange][needs landing] → [orange]
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1264606600.1264607286.10129.gz WINNT 5.2 mozilla-central opt test mochitests-2/5 on 2010/01/27 07:36:40 s: win32-slave34
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1267570090.1267571242.32641.gz WINNT 5.2 mozilla-central opt test mochitests-2/5 on 2010/03/02 14:48:10 s: win32-slave37
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1268370180.1268372502.10804.gz WINNT 5.2 mozilla-central debug test mochitests-2/5 on 2010/03/11 21:03:00
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1269300561.1269302577.5699.gz WINNT 5.2 mozilla-central debug test mochitests-2/5 on 2010/03/22 16:29:21
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1270979347.1270983329.17633.gz Linux comm-central-trunk debug test mochitests-2/5 on 2010/04/11 02:49:07
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272346681.1272347557.23698.gz WINNT 5.2 mozilla-central opt test mochitests-2/5 on 2010/04/26 22:38:01 s: win32-slave11
Summary: mochitest-plain: intermittent "test_bug369814.html | iframes.html loaded from view-source jar type, pref disabled: should block a suspicious JAR load" → mochitest-plain: intermittent "test_bug369814.html | iframes.html loaded from view-source jar type (or from non-jar type), pref disabled: should block a suspicious JAR load"
This has been happening a _lot_ recently. It's worrying me that we might have an actual security hole here...
blocking2.0: --- → ?
TopFails (all 4 apps) doesn't list this test :-(
Depends on: 565307
Wild guess probably, but since some of the previous logs show a warning about not being able to retrieve the pref plugins.unloadASAP before the test failure, could we fail at the call to the pref-service somehow? In other words, would we get a warning/assertion if the call to setBoolPref in that testcase failed?
If setBoolPref failed in the testcase in the throw-an-exception sense, the test would fail due to triggering window.onerror and never run the view-source test.... But maybe prefs is just lying about the value?
Boris, could you dig a bit deeper here and either unblock if this is not as bad as it is, or fix or reassign as needed if we need to fix this for 2.0?
Assignee: nobody → bzbarsky
blocking2.0: ? → final+
Keywords: checkin-needed
Keywords: checkin-needed
Priority: -- → P1
Whiteboard: [orange] → [orange] softblocker
Whiteboard: [orange] softblocker → [orange][softblocker]
** PRODUCT DRIVERS PLEASE NOTE ** This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons: - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
Ah. I bet the issue here is this. loadErrorTest does: 73 gTestFrame.src = test['url']; 74 75 // Give the frame a chance to fail at loading 76 setTimeout(function() { 77 // XXX: There doesn't seem to be a reliable check for "got an error," 78 // but reaching in to an error document will throw an exception .... 89 }, gLoadTimeout); where gLoadTimeout is 3000. I bet if the load is just really slow this could fail....
Blocks: FlakyTimeout
So there were several issues here: 1) The code in bug 369814 was wrong. 2) The test was wrong and didn't catch the issue from #1. 3) The problem from comment 79. Fixes coming up for all three.
Whiteboard: [orange][softblocker] → [need review][orange][softblocker]
Attachment #529828 - Flags: review?(ehsan) → review+
Attachment #529826 - Flags: review?(jst) → review+
Attachment #529827 - Flags: review?(jst) → review+
Whiteboard: [need review][orange][softblocker] → [need landing][orange][softblocker]
Pushed: http://hg.mozilla.org/mozilla-central/rev/e64eb8c66849 http://hg.mozilla.org/mozilla-central/rev/bf1a9f0c18e0 http://hg.mozilla.org/mozilla-central/rev/5a456fd32d3d
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [need landing][orange][softblocker] → [orange][softblocker]
Target Milestone: --- → mozilla6
Attachment #529826 - Attachment description: part 1. Move the detection of loads inheriting a principal later in InternalLoad so that we catch ones that pass in a non-null owner directly. → part 1. Move the detection of loads inheriting a principal later in InternalLoad so that we catch ones that pass in a non-null owner directly [Checked in: Comment 84]
Attachment #529827 - Attachment description: part 2. Change the test to catch the error fixed in part 1 in the future. This is just removing an extra .parent from the scripts in anchors.html inside the zip file. → part 2. Change the test to catch the error fixed in part 1 in the future. This is just removing an extra .parent from the scripts in anchors.html inside the zip file [Checked in: Comment 84]
Attachment #529828 - Attachment description: part 3. Stop using timeouts in the test. zip file change is just a change to replace top.poke() with parent.poke() so that the refresh test will be useful in the harness too. → part 3. Stop using timeouts in the test. zip file change is just a change to replace top.poke() with parent.poke() so that the refresh test will be useful in the harness too [Checked in: Comment 84]
Whiteboard: [orange][softblocker] → [softblocker]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: