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

()

defect
P1
normal
RESOLVED FIXED
10 years ago
7 years ago

People

(Reporter: sgautherie, Assigned: bzbarsky)

Tracking

({intermittent-failure})

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

Firefox Tracking Flags

(blocking2.0 .x+)

Details

(Whiteboard: [softblocker], )

Attachments

(4 attachments)

Reporter

Description

10 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

10 years ago
Blocks: 438871
Whiteboard: [orange]
Reporter

Comment 1

10 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: SmTestFail
Summary: mochitest-plain: test_bug369814.html intermittently fails → [SeaMonkey? Windows?] mochitest-plain: test_bug369814.html intermittently fails
Reporter

Comment 2

10 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

10 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

10 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

10 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: 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]

Updated

10 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]
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/1269300561.1269302577.5699.gz
WINNT 5.2 mozilla-central debug test mochitests-2/5 on 2010/03/22 16:29:21
Reporter

Comment 22

9 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 (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/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 (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/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 (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Reporter

Comment 47

9 years ago
TopFails (all 4 apps) doesn't list this test :-(
Depends on: 565307
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/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 (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/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 (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)

Updated

9 years ago
Keywords: checkin-needed
Reporter

Updated

9 years ago
Keywords: checkin-needed
Comment hidden (Legacy TBPL/Treeherder Robot)
Priority: -- → P1
Whiteboard: [orange] → [orange] softblocker
Whiteboard: [orange] softblocker → [orange][softblocker]
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/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 (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/Treeherder Robot)
Comment hidden (Legacy TBPL/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....
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
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [need landing][orange][softblocker] → [orange][softblocker]
Target Milestone: --- → mozilla6
Reporter

Updated

8 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

8 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

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