Closed Bug 483388 Opened 15 years ago Closed 15 years ago

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

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: sgautherie, Unassigned)

References

(Blocks 1 open bug)

Details

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

[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?
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.
Interestingly, the same test passes on the Firefox test tinderboxes.
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.
(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...
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.
(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.
Blocks: 483385
Blocks: 483553
(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)
[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
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.
[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...
(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 !
(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.
(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]
Depends on: 443331
Whiteboard: [Workaround: comment 19] → [Workaround: comment 19] [Does depend on bug 443331]
[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
Closed: 15 years ago
Flags: wanted1.9.2?
Resolution: --- → INVALID
Keywords: regression
You need to log in before you can comment on or make changes to this bug.