Closed Bug 745788 Opened 8 years ago Closed 8 years ago

Intermittent a11y/accessible/treeupdate/test_imagemap.html | Test timed out

Categories

(Core :: Disability Access APIs, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla19

People

(Reporter: philor, Assigned: surkov)

References

(Blocks 2 open bugs)

Details

(Keywords: intermittent-failure)

Attachments

(3 files, 1 obsolete file)

See also several instances put in the SeaMonkey permaorange bug 738146.

https://tbpl.mozilla.org/php/getParsedLog.php?id=10940415&tree=Mozilla-Inbound
Rev3 WINNT 5.1 mozilla-inbound debug test mochitest-other on 2012-04-16 07:19:37 PDT for push 7775694dcfe5

23951 INFO TEST-INFO | chrome://mochitests/content/a11y/accessible/treeupdate/test_imagemap.html | Invoke the 'restore @name on map element' test { expected 'hide' event; expected 'show' event; expected 'reorder' event;  }
NOTE: child process received `Goodbye', closing down
NPP_Destroy
NPP_Destroy
nsStringStats
 => mAllocCount:             94
 => mReallocCount:            1
 => mFreeCount:              94
 => mShareCount:            135
 => mAdoptCount:              0
 => mAdoptFreeCount:          0
WARNING: 1 sort operation has occurred for the SQL statement '0x14a1c800'.  See https://developer.mozilla.org/En/Storage/Warnings details.: file e:/builds/moz2_slave/m-in-w32-dbg/build/storage/src/mozStoragePrivateHelpers.cpp, line 144
23952 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/treeupdate/test_imagemap.html | Test timed out.
(screenshot)
23953 INFO TEST-END | chrome://mochitests/content/a11y/accessible/treeupdate/test_imagemap.html | finished in 316285ms
Trevor, have you had a chance to take a look at this now the logging has landed? :-)
WARNING: NS_ENSURE_TRUE(parentObject) failed: file /builds/slave/m-beta-lnx64-dbg/build/accessible/src/atk/nsAccessibleWrap.cpp, line 1397
mozilla-beta debug test mochitest-other on 2012-06-23
Rev3 WINNT 6.1 mozilla-inbound opt test mochitest-other on 2012-06-24 13:50:19 PDT for push 85e7655b9ac0

24436 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/a11y/accessible/treeupdate/test_imagemap.html | Test timed out.

args: ['c:\\talos-slave\\test\\build\\bin\\screenshot.exe', 'c:\\users\\cltbld\\appdata\\local\\temp\\mozilla-test-fail_u-lnnn']
Boris, do you know if nsImageMap::UpdateAreas() (http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsImageMap.cpp#793) might not trigger when setting up @name attribute on map element:

<map id="map">
  <area href="http://www.bbc.co.uk/radio4/atoz/index.shtml#b"
        coords="17,0,30,14" alt="b" shape="rect">
</map>

<img id="imgmap" width="447" height="15"
         usemap="#atoz_map"
         src="../letters.gif">

mapNode.setAttribute("name", "atoz_map");
Changing @name on the <map> element won't trigger UpdateAreas(), but it _will_ trigger mImageFrame->DisconnectMap().
(In reply to Boris Zbarsky (:bz) from comment #223)
> Changing @name on the <map> element won't trigger UpdateAreas(), but it
> _will_ trigger mImageFrame->DisconnectMap().

oh, right. How long that 'will' can be? Can the mochitest run out of time waiting for it?
DisconnectMap() just calls Destroy() on the nsImageMap, nulls out the pointer, and recreates the accessible for the image.

How long that will take depends on how many areas there are, obviously.  But I would not expect it to take more than "milliseconds".
Attached patch patchSplinter Review
enable more logging
Attachment #665289 - Flags: review?(trev.saunders)
Attachment #665289 - Flags: review?(trev.saunders) → review+
I think I've figured out the problem here.

We hang in 'insert map element'. There is already an image visible in the window, with a usemap attribute pointing to a nonexistent element. The test adds a <map> element with the id referenced by usemap. The test expects accessibility events indicating that the image was removed and replaced by the map, but not such events arrive.

The reason is that there is simply nothing to trigger any activity when the map element is added. The reason this test sometimes passes is that when we paint the image, nsImageFrame::PaintImage calls GetImageMap which checks the DOM to see if usemap points to a <map>. But if nothing causes the image to be repainted, we won't ever notice the <map> has been created.
Note that also, if the image is offscreen, we won't ever paint it and these accessibility events will not be dispatched.
The best fix for this is probably to have nsImageFrame use nsReferencedElement to find its map. nsReferencedElement knows how to handle this case.
Attached patch workaround imagemap bug (obsolete) — Splinter Review
Assignee: nobody → roc
Attachment #665776 - Flags: review?(trev.saunders)
I don't want to fix imagemaps right now.
Attachment #665776 - Flags: review?(trev.saunders) → review+
Attached patch fixSplinter Review
Cleaned up to remove debugging printfs. carrying forward r+.
Attachment #665776 - Attachment is obsolete: true
Attachment #665780 - Flags: review+
Whiteboard: [orange] → [orange][leave open]