All users were logged out of Bugzilla on October 13th, 2018

[SeaMonkey] Chrome test_bug444800.xul fails now, throwing an exception

RESOLVED INVALID

Status

()

RESOLVED INVALID
10 years ago
9 years ago

People

(Reporter: sgautherie, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Windows 2000
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Workaround: comment 19] [Does depend on bug 443331])

(Reporter)

Description

10 years ago
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090308 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/537eccc6c218
 +http://hg.mozilla.org/comm-central/rev/ce8ad6fa9801)

Test passes.

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

{
6007 INFO Running chrome://mochikit/content/chrome/widget/tests/test_bug444800.xul...
6008 INFO TEST-PASS | chrome://mochikit/content/chrome/widget/tests/test_bug444800.xul | have copy command
6009 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/widget/tests/test_bug444800.xul | image/png - hasDataMatchingFlavors()
6010 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/widget/tests/test_bug444800.xul | Error thrown during test: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsITransferable.getAnyTransferData]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://mochikit/content/chrome/widget/tests/test_bug444800.xul :: runImageClipboardTests :: line 58"  data: no] - got 0, expected 1
}

(4 days) Regression timeframes:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-03-08+01%3A39%3A45&enddate=2009-03-12+06%3A45%3A41
http://hg.mozilla.org/comm-central/pushloghtml?startdate=2009-03-08+04%3A31%3A54&enddate=2009-03-12+01%3A54%3A20
Flags: wanted1.9.2?

Comment 1

10 years ago
Making a stab to attempt to find the checkin that broke this clipboard test:

joe@drew.ca  bug 481753 http://hg.mozilla.org/mozilla-central/rev/987a23d40e86
vlad         bug 480088 http://hg.mozilla.org/mozilla-central/rev/6819e10ecb9e

(Sorry I don't have more time to investigate right now)
Both of those are pretty unlikely.. would be helpful to get a narrower regression range here.

Comment 3

10 years ago
Interestingly, the same test passes on the Firefox test tinderboxes.

Comment 4

10 years ago
Is this Windows-specific or do other platforms also fail?

I can't imagine what front-end code would affect the presence of image clipboard data.
(Reporter)

Comment 5

10 years ago
(In reply to comment #4)
> Is this Windows-specific or do other platforms also fail?

No idea: Windows is the only platform I build.

> I can't imagine what front-end code would affect the presence of image
> clipboard data.

I haven't checked in details, but the clipboard feature seems globally broken...

Comment 6

10 years ago
For comparison, I've just tried the Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090313 Shredder/3.1a1pre nightly comm-central/ mozilla-central build. Pasting an image from the clipboard, put there with MS-Paint, works fine in both PNG and JPEG formats. No errors reported.

Thus, this issue appears to be specific to SeaMonkey rather than Core.

> but the clipboard feature seems globally broken...

Are you saying that you can't paste anything at all, including text?
That definitely should be independent from bug 444800 then.
(Reporter)

Comment 7

10 years ago
(In reply to comment #6)
> > but the clipboard feature seems globally broken...
> 
> Are you saying that you can't paste anything at all, including text?

More detailed check:

'copy' doesn't work within the browser window used to run a11y test suite (this is where I tested at first) ... but that may be expected (at least unrelated) ??

Testing it in a (new) regular profile browser window, copy+paste both work.

> That definitely should be independent from bug 444800 then.

That is just when the test was added.
(Reporter)

Updated

10 years ago
Blocks: 483385
(Reporter)

Updated

10 years ago
Blocks: 483553
(Reporter)

Comment 12

10 years ago
(In reply to comment #11)
> [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090316
> SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
> (http://hg.mozilla.org/mozilla-central/rev/bea12faeea80
>  +http://hg.mozilla.org/comm-central/rev/d12dee2e9db1)
> 
> Fails.

Backing out changeset d12dee2e9db1 makes no difference: not comm-central related. (as expected)
(Reporter)

Comment 13

10 years ago
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090316 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/d85e2a66d940
 +http://hg.mozilla.org/comm-central/rev/4a8ddefbf08e)

Pass.

(4 changesets) Regression timeframe:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-03-10+09%3A26%3A17&enddate=2009-03-10+12%3A33%3A51
Probably bug 424377 ?
Keywords: regressionwindow-wanted

Comment 14

10 years ago
Why bug 424377? That changes only print / print preview.
http://mxr.mozilla.org/mozilla-central/source/widget/tests/test_bug444800.xul
doesn't seem to test printing.
(Reporter)

Comment 15

10 years ago
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090316 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/c3d89722f165
 +http://hg.mozilla.org/comm-central/rev/4a8ddefbf08e)

Fails.

(2 changesets) Regression timeframe:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-03-10+09%3A26%3A17&enddate=2009-03-10+12%3A13%3A48

(In reply to comment #13)
> Probably bug 424377 ?

It seems not.
Then, I'd have blamed bug 465158, but it was later backed out.
So, this would leave bug 481372 only...
(Reporter)

Comment 16

10 years ago
(In reply to comment #14)
> Why bug 424377?

I just found out in the meantime :->


(In reply to comment #15)
> So, this would leave bug 481372 only...

Bug 481732 !
(Reporter)

Comment 17

10 years ago
(In reply to comment #15)
> So, this would leave bug 481732 only...

Confirmed. (as much as I would not have suspected that one)

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

Fails.

Exact regression timeframe:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-03-10+09%3A26%3A17&enddate=2009-03-10+10%3A36%3A40
Blocks: 481732
I'm a bit stumped as to how that change could change any test behavior. While it does touch the harness code, it doesn't change the way the app is run at all.
(Reporter)

Comment 19

10 years ago
(In reply to comment #18)
> I'm a bit stumped as to how that change could change any test behavior. While

So was I, but who ever knows ;-/

> it does touch the harness code, it doesn't change the way the app is run at
> all.

If I comment out |env['MOZ_CRASHREPORTER'] = '1'| in automation.environment() then the test passes.
After that, even if I restore that line, the test still passes ... until I wait a (short) moment without running it, after what it starts to fail again.

|env['MOZ_CRASHREPORTER_NO_REPORT'] = '1'| being active/disabled doesn't matter.

It looks like activating the crashreporter feature is braking up something else !?
(I don't know whether it's my computer only or not...)
Whiteboard: [Workaround: comment 19]
(Reporter)

Updated

10 years ago
Depends on: 443331
(Reporter)

Updated

10 years ago
Whiteboard: [Workaround: comment 19] → [Workaround: comment 19] [Does depend on bug 443331]
(Reporter)

Comment 20

9 years ago
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090711 SeaMonkey/2.1a1pre] (home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/47bfcd275ede
 +http://hg.mozilla.org/comm-central/rev/291cbe3374b9)

R.Invalid, after upgrading to recent TortoiseHg v0.8.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Flags: wanted1.9.2?
Resolution: --- → INVALID
(Reporter)

Updated

9 years ago
Keywords: regression
You need to log in before you can comment on or make changes to this bug.