Bug 101811 – Multi-frame CUR file test hangs on mac port

• Status: RESOLVED
• Resolution: FIXED
• Component: Images

[Rick Byers]

In bug 100059 I'm adding some tests for handling of CUR format cursor files.  

One unusual case that I'm testing is a CUR file that contains multiple frames of images (each encoded using PNG).  The Mac port (which uses Core Graphics for ICO/CUR image decoding instead of the ICOImageDecoder all other ports use) appears to hang sometimes when loading this file, causing my test to timeout.  When I run the safari I built directly I also see it hang the first time it tries to load this file (but if I stop loading and reload, then it fails quickly).

I've never done any mac development, and don't know anything about Core Graphics, so I'm just going to disable this one weird test on Mac.  I still want to get the coverage of ICOImageDecoder used on other ports though.  I haven't been able to reproduce this hang using the build of safari that comes with the OS, but it did repro in both Debug and Release builds I built today from WebKit ToT.  This is on MacOS X 10.7.5 on a Retina macbook pro.

[Alexey Proskuryakov]

Can you please provide steps to reproduce this issue? Which test should I open to make Safari hang?

[Rick Byers]

The test in question hasn't quite landed yet (hence blocked in bug 100059).  But in that patch it's test 'fast/events/mouse-cursor-multiframecur.html' that hangs on safari.

[Alexey Proskuryakov]

This test has been landed. When I try to open it in Safari 6.0.2 on OS X 10.8.2, I get some error output:

FAIL This test requires DumpRenderTree
PASS successfullyParsed is true

TEST COMPLETE
FAIL Got unexpected 'error' event for image: file:///Users/ap/Safari/OpenSource/LayoutTests/fast/events/resources/greenbox-3frames.cur

Please do provide steps to reproduce this issue.

[Alexey Proskuryakov]

I also cannot reproduce on 10.7.5.

Please also attach a sample of a hung WebProcess (you can take one from Activity Monitor, or with command line "sample" tool).

[Rick Byers]

Since I reported this I've updated my Mac to 10.8.2.  The hang in safari no longer reproduces for me.  I'm not sure if that means there was really an OS issue in 10.7, or (seemingly more likely) there was some unrelated issue in WebKit ToT at the time that's been fixed now.

Regardless, there was ALSO a bug in the test that would cause the test to hang when the last image failed to load.  So the hang I saw running safari loading this test could have been completely unrelated to the test hang.  Sorry for the confusion!

I'll submit a patch that fixes the test hang and re-enables it.

[Rick Byers]

Created attachment 174803 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 174803 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=174803&action=review

> LayoutTests/platform/mac/fast/events/mouse-cursor-multiframecur-expected.txt:9
> +FAIL Got unexpected 'error' event for image: file:///Users/rbyers/code/chromium/src/third_party/WebKit/LayoutTests/fast/events/resources/greenbox-3frames.cur

What causes this failure? Is there a bug tracking it?

[Alexey Proskuryakov]

Comment on attachment 174803 [details]
Patch

Of course, this expected result cannot be matched on anyone else's machine, because it contains a local path.

[Build Bot]

Comment on attachment 174803 [details]
Patch

Attachment 174803 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/14879196

New failing tests:
fast/events/mouse-cursor-multiframecur.html
inspector-protocol/nmi-webaudio.html

[Rick Byers]

(In reply to comment #7)
> (From update of attachment 174803 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=174803&action=review
> 
> > LayoutTests/platform/mac/fast/events/mouse-cursor-multiframecur-expected.txt:9
> > +FAIL Got unexpected 'error' event for image: file:///Users/rbyers/code/chromium/src/third_party/WebKit/LayoutTests/fast/events/resources/greenbox-3frames.cur
> 
> What causes this failure? Is there a bug tracking it?

I assume the CoreGraphics CUR file support doesn't support multi-frame CUR files.  That's probably not unreasonable - it's not precisely clear what the right behavior is for them.  The code used by other ports does the same thing it does with multi-frame ICO files when no specific frame is requested: use the frame with the highest quality (specifically pixel count, then color depth).

(In reply to comment #8)
> (From update of attachment 174803 [details])
> Of course, this expected result cannot be matched on anyone else's machine, because it contains a local path.

Yes, of course - duh.  I'll change the error-handling to strip the path.  Sorry.

[Rick Byers]

Created attachment 174869 [details]
Patch

[Rick Byers]

Created attachment 174871 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 174871 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=174871&action=review

> LayoutTests/fast/events/mouse-cursor-multiframecur.html:30
> +        // appear to support multi-frame CUR files, so the load will fal in this case.

s/fal/fail/

[Rick Byers]

Created attachment 175531 [details]
Patch for landing

[Rick Byers]

(In reply to comment #13)
> (From update of attachment 174871 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=174871&action=review
> 
> > LayoutTests/fast/events/mouse-cursor-multiframecur.html:30
> > +        // appear to support multi-frame CUR files, so the load will fal in this case.
> 
> s/fal/fail/

Done, thanks!

[WebKit Review Bot]

Comment on attachment 175531 [details]
Patch for landing

Clearing flags on attachment: 175531

Committed r135444: <http://trac.webkit.org/changeset/135444>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.