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"

RESOLVED FIXED in mozilla6

Status

()

Core
Networking: JAR
P1
normal
RESOLVED FIXED
8 years ago
5 years ago

People

(Reporter: sgautherie, Assigned: bz)

Tracking

({intermittent-failure})

Trunk
mozilla6
x86
All
intermittent-failure
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 .x+)

Details

(Whiteboard: [softblocker], URL)

Attachments

(4 attachments)

(Reporter)

Description

8 years ago
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.
(Reporter)

Updated

8 years ago
Blocks: 438871
Whiteboard: [orange]
(Reporter)

Comment 1

8 years ago
(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: 452942
Summary: mochitest-plain: test_bug369814.html intermittently fails → [SeaMonkey? Windows?] mochitest-plain: test_bug369814.html intermittently fails
(Reporter)

Comment 2

8 years ago
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.
}
(Reporter)

Comment 3

8 years ago
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
(Reporter)

Comment 4

8 years ago
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.
(Reporter)

Comment 6

8 years ago
(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: 452942
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"
(Reporter)

Comment 10

8 years ago
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1260569052.1260577045.32309.gz
WINNT 5.2 comm-1.9.1 unit test on 2009/12/11 14:04:12
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.
Created attachment 418280 [details] [diff] [review]
fix test
[Checked in: Comment 16 & 67]

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]

Updated

8 years ago
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]
Keywords: checkin-needed
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1264112159.1264114149.22755.gz
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
(Reporter)

Comment 22

7 years ago
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
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
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"
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
This has been happening a _lot_ recently.  It's worrying me that we might have an actual security hole here...
blocking2.0: --- → ?
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
(Reporter)

Comment 47

7 years ago
TopFails (all 4 apps) doesn't list this test :-(
Depends on: 565307
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
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?
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
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+
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Keywords: checkin-needed
(Reporter)

Updated

7 years ago
(Reporter)

Comment 67

7 years ago
Comment on attachment 418280 [details] [diff] [review]
fix test
[Checked in: Comment 16 & 67]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/049befb15069

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/42df09ddc380
Attachment #418280 - Attachment description: fix tst → fix test [Checked in: Comment 16 & 67]
(Reporter)

Updated

7 years ago
Keywords: checkin-needed
Comment hidden (Treeherder Robot)
Priority: -- → P1

Updated

7 years ago
Whiteboard: [orange] → [orange] softblocker

Updated

7 years ago
Whiteboard: [orange] softblocker → [orange][softblocker]
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
** 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+
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
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: 649012
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.
Created attachment 529826 [details] [diff] [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]
Attachment #529826 - Flags: review?(jst)
Created attachment 529827 [details] [diff] [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]
Attachment #529827 - Flags: review?(jst)
Created attachment 529828 [details] [diff] [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]
Attachment #529828 - Flags: review?(ehsan)
Whiteboard: [orange][softblocker] → [need review][orange][softblocker]
Attachment #529828 - Flags: review?(ehsan) → review+

Updated

6 years ago
Attachment #529826 - Flags: review?(jst) → review+

Updated

6 years ago
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
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [need landing][orange][softblocker] → [orange][softblocker]
Target Milestone: --- → mozilla6
(Reporter)

Updated

6 years ago
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]
(Reporter)

Updated

6 years ago
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]
(Reporter)

Updated

6 years ago
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]
Keywords: intermittent-failure
Whiteboard: [orange][softblocker] → [softblocker]
You need to log in before you can comment on or make changes to this bug.