115481 - When focus is on imagemap, ALL key events go dead

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[John Morrison]

Once you tab into a imagemap, giving it focus, all key events go dead. You
can't tab out of the imagemap, or keyboard access the menus (e.g., alt-F), or
use any shortcuts (e.g., ctrl-L)

This was not occurring in builds of 12/05, but was broken in builds of
12/06. bryner thought it might be related to dbaron's checkin (12/5 pm) for
removal of nsDST (bug 110911) [e.g., "Give image map area structures a pointer
back to their image frame rather than (mis)using the primary frame map.")

Will attach a testcase in a moment. (Giving to bryner, but who's bug should 
this be? Does anyone own imagemap?)

Comment 1

[John Morrison]

Attachment: test case from cnn.com; tab through the links until it goes dead on the imagemap

Comment 2

[Nick Kocharhook]

WFM Fizzilla 0.9.6 build 2001112020

Comment 3

[Brian Ryner (not reading)]

> WFM Fizzilla 0.9.6 build 2001112020

Please read the bug fully before adding useless comments, we've already
established that it broke between 12/5 and 12/6.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

*** Bug 115965 has been marked as a duplicate of this bug. ***

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: revert the relevant part of my changes to fix this bug

There's a chance this may also fix bug 114377 -- I'd need someone with Windows
to test that.

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Taking.

Comment 7

[John Morrison]

The patch http://bugzilla.mozilla.org/attachment.cgi?id=63084 fixes both the 
key-dead situation for this bug, and the crash on right click for bug 114377
[current trunk win2k.]

Comment 8

[Brian Ryner (not reading)]

Comment on attachment 63084 [details] [diff] [review]
revert the relevant part of my changes to fix this bug

r=bryner

Comment 9

[Dimitrios]

*** Bug 117772 has been marked as a duplicate of this bug. ***

Comment 10

[Marc Attinasi]

Comment on attachment 63084 [details] [diff] [review]
revert the relevant part of my changes to fix this bug

sr=attinasi

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Well, today's not a good day to check in.  There was a stuck cvs lock in
layout/html/base/src/

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Fix checked in 2001-01-05 07:22 PDT.  I need to file a new bug on a long-term
solution before I close this one...

Comment 13

[Pete Zha]

Still see this bug on trunk build20010401 window2000
Is this dup of bug 124789?

Comment 14

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

No, this bug is basically fixed, I'm just leaving it open because we need a new
bug on a better solution.

Comment 15

[Gilbert Fang]

Attachment: a test case for image map showing focus errors

it is a zip including a html page and two gif images. Open it and use tab to
switch	the focus. Pay attention to the focus on the two images. The focus is
fosuing on the two images at the same time!!!!!

Comment 16

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Please file a new bug.  This one is fixed.

Comment 17

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I filed bug 135040 on the issue in comment 12.  Please file a new bug on comment
13 / comment 15.

Comment 18

[Gilbert Fang]

Hi, david
Your response is really quick. Please let me complete my words.
sorry to bother you again and please give me some suggestions.

I think this fix is just a workaround. Actually, there is some lacuna in the
layout model. Normally the function FindPrimaryFramFor can find a frame for a
nsIContent.
But for the image map, it is different. In my test case, the image map is one 
dom node which is  referenced by the two images.Then how do I tell which image
should be the primary frame for that image map. I think that is reason in my
test case.

Another problem: in bug 124789, the bug is because the FindPrimaryFrameFor can
not find a primary frame for  the nsIContent standing  for image map areas when
it is not showed on the screen. But when the image is showed once, it seems to
work correctly. I trace the process to find that is because we can find a
primary frame for the  image map areas and this mapping is in Hash table. I
assume when the image is showed, a mapping connecting  the image map and the
image frame is inserted into the hash table which is from this bug's fix. It is
not really a solution for the mapping between the nsIFrame and nsIContents.


By the way , why the hash table does not have the maping when the image is not
showed for the first time? I think it is at least a workaround for the bug 124789.
 

Comment 19

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Whatever you're talking about is a *different* bug.  This bug was about key
events going completely dead anytime anyone tabbed into an imagemap.  Please
file a different bug.  This one is fixed.

Comment 20

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

It may be true that the current multiple-mappings solution for imagemaps causes
problems.  If so, that's could be relevant on bug 135040, but not on this bug. 
This bug was merely about restoring that solution to get things working again.

Comment 21

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

It looks like the issue in comment 15 was filed as bug 135083.