Closed Bug 474152 Opened 11 years ago Closed 11 years ago

[SeaMonkey] TUnit toolkit/.../test_contentAreaUtils.js fails after bug 464795 landing

Categories

(SeaMonkey :: Download & File Handling, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.0b1

People

(Reporter: sgautherie, Assigned: sgautherie)

References

(Blocks 1 open bug, )

Details

(Keywords: regression, verified1.9.1, Whiteboard: [fixed1.9.1b99])

Attachments

(1 file)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090110 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/6acaaa957e0a
 +http://hg.mozilla.org/comm-central/rev/865f907bb16b)

{
*** test finished
*** exiting
*** PASS ***
}

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090117 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/a3abe1807f71 + bug 446300 patch
 +http://hg.mozilla.org/comm-central/rev/da4ab57196d6 + bug 446300 patch)

{
[Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: chrome://global/content/contentAreaUtils.js :: <TOP_LEVEL> :: line 421"  data: no]
*** FAIL ***
}

The triggering line, in the test is
{
  loader.loadSubScript("chrome://global/content/contentAreaUtils.js");
}
As a confirmation s/global/communicator/ makes it pass.

(m-c) Regression timeframe:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6acaaa957e0a&tochange=a3abe1807f71
As a wild guess, maybe bug 441359 ?

NB: Currently, bug 473734 prevents all following tests (including this one) from even running on the 1.9.1 SM boxes.
Flags: wanted1.9.2?
Run it with
env XPCOM_MEM_LEAK_LOG=1 make SOLO_FILE="test_contentAreaUtils.js" -C objdir/mozilla/toolkit/content/tests check-one
(In reply to comment #0)
> NB: Currently, bug 473734 prevents all following tests (including this one)
> from even running on the 1.9.1 SM boxes.

That bug was fixed and SM/1.9.1 passes this test:
this bug is SM/1.9.2 specific.
No longer depends on: 473734
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090118 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/6e4203c77ce9
+http://hg.mozilla.org/comm-central/rev/306be9e163b0)

Pass.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090118 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/aa198b35552d
+http://hg.mozilla.org/comm-central/rev/c5c795d2335c)

Fail.

Narrower (3 days "only") regression timeframe:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6e4203c77ce9&tochange=aa198b35552d
(In reply to comment #0)
> As a wild guess, maybe bug 441359 ?

Not that one.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090126 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/44890ee1d15f
+http://hg.mozilla.org/comm-central/rev/ce533e4625e8)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090126 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/167b82ee7162
+http://hg.mozilla.org/comm-central/rev/306be9e163b0)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090126 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/66071c6b43a9
+http://hg.mozilla.org/comm-central/rev/f13a45c4f1f9)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090126 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/98e0b6b69e05
+http://hg.mozilla.org/comm-central/rev/4d2ac69754e9)

Pass.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090126 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/c8faab9608dc
+http://hg.mozilla.org/comm-central/rev/4d2ac69754e9)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090126 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/23adb1fb2e1b
+http://hg.mozilla.org/comm-central/rev/f1e4747febbf)

Fail.

Exact regression timeframe:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=98e0b6b69e05&tochange=c8faab9608dc
This is bug 464795.
Blocks: 464795
Is this URL available in SeaMonkey?

<resource://gre/modules/DownloadLastDir.jsm>
Component: Security → Download & File Handling
Product: Toolkit → SeaMonkey
QA Contact: toolkit → download
The patch would be very simple: just add DownloadLastDir.jsm to EXTRA_JS_MODULES in comm-central/source/mozilla/xpfe/components/download-manager/src/Makefile.in.  I don't have a comm-central checkout handy right now; can someone please create the patch?
Ehsan, unless this lands in 1.9.1 very soon, I'd like to keep any patching out of mozilla/xpfe/components/download-manager/ as we're working on completely moving away from that piece of xpfe code and over to toolkit in the next weeks, see bug 381157.

Callek, one more reason to get the dlmgr patch ready ASAP ;-)
(In reply to comment #8)
> Ehsan, unless this lands in 1.9.1 very soon, I'd like to keep any patching out
> of mozilla/xpfe/components/download-manager/ as we're working on completely
> moving away from that piece of xpfe code and over to toolkit in the next weeks,
> see bug 381157.

I have requested approval to land it on 1.9.1, and the original patch seems to have a problem which I need to fix before landing on 1.9.1, so no this isn't going to land very soon, but OTOH I don't know about the time frame for retiring the xpfe download manager...
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090129 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/9864a75ee19e + bug 474152 patch
 +http://hg.mozilla.org/comm-central/rev/f61570d094c5)

Asking for review, in case a fix would become wanted later.
Assignee: nobody → sgautherie.bz
Status: NEW → ASSIGNED
Attachment #359435 - Flags: review?(kairo)
Depends on: 381157
OS: Windows 2000 → All
Hardware: x86 → All
Summary: [SeaMonkey] toolkit/.../test_contentAreaUtils.js fails now → [SeaMonkey] TUnit toolkit/.../test_contentAreaUtils.js fails now
Comment on attachment 359435 [details] [diff] [review]
(Av1) Package DownloadLastDir.jsm
[Checkin: Comment 17 & 18]

if you can get at least one member of council (incl KaiRo) to rs+ this, and Neil to sr+ on the code (as this is xpfe sr required) I feel we can take this if it will fail-out our unit boxen should this land before the DLMGR backend.  My code already will stop this makefile from running once it lands, so no conflicts there.

(All we are doing with this patch is adding a jsm to the dist dir, that is not even packaged so we can be sure to pass tests)
Attachment #359435 - Flags: review+
Comment on attachment 359435 [details] [diff] [review]
(Av1) Package DownloadLastDir.jsm
[Checkin: Comment 17 & 18]

err remind me not to skim bugmail when I'm tired... "ifndef" from that makes me feel we shouldn't take this...
Attachment #359435 - Flags: review+
Attachment #359435 - Flags: superreview?(neil)
Attachment #359435 - Flags: superreview?(neil) → superreview+
Comment on attachment 359435 [details] [diff] [review]
(Av1) Package DownloadLastDir.jsm
[Checkin: Comment 17 & 18]

sr=me, but only if bug 464795 lands on 1.9.1 before we switch to toolkit download manager, and without the ifdef.
Blocks: 381157
No longer depends on: 381157
FWIW, I expect bug 464795 to land on 1.9.1 in the next few days; just a little heads-up.
Bug 464795 just landed on 1.9.1.
Comment on attachment 359435 [details] [diff] [review]
(Av1) Package DownloadLastDir.jsm
[Checkin: Comment 17 & 18]

r=me as a one-liner without the ifndef and within the existing EXTRA_JS_MODULES assignment.
Attachment #359435 - Flags: review?(kairo) → review+
Comment on attachment 359435 [details] [diff] [review]
(Av1) Package DownloadLastDir.jsm
[Checkin: Comment 17 & 18]


http://hg.mozilla.org/mozilla-central/rev/0dffee5de077
Attachment #359435 - Attachment description: (Av1) Package DownloadLastDir.jsm → (Av1) Package DownloadLastDir.jsm [Checkin: Comment 17]
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: wanted1.9.2? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
No longer blocks: CcMcBuildIssues
Comment on attachment 359435 [details] [diff] [review]
(Av1) Package DownloadLastDir.jsm
[Checkin: Comment 17 & 18]


http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b26617c9b2c8
Attachment #359435 - Attachment description: (Av1) Package DownloadLastDir.jsm [Checkin: Comment 17] → (Av1) Package DownloadLastDir.jsm [Checkin: Comment 17 & 18]
No longer blocks: 464795
Depends on: 464795
Keywords: fixed1.9.1
Summary: [SeaMonkey] TUnit toolkit/.../test_contentAreaUtils.js fails now → [SeaMonkey] TUnit toolkit/.../test_contentAreaUtils.js fails after bug 464795 landing
Whiteboard: [fixed1.9.1rc1]
Duplicate of this bug: 489077
verified1.9.1, per bug 489077 comment 7.
Target Milestone: mozilla1.9.2a1 → seamonkey2.0b1
Whiteboard: [fixed1.9.1rc1] → [fixed1.9.1b99]
You need to log in before you can comment on or make changes to this bug.