WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
50169
REGRESSION (
r53857
): Removing focus from area element causes unwanted scrolling
https://bugs.webkit.org/show_bug.cgi?id=50169
Summary
REGRESSION (r53857): Removing focus from area element causes unwanted scrolling
Martin Stricker
Reported
2010-11-29 12:03:39 PST
See Testpage:
http://strickr.de/tests/imagemap.html
Der dots on the map are connected via anchor links to entries in a list below: - clicking on a dot scrolls down to entry in list (as expected) - on next click in window (no matter if on link or not) page jumps up again to image (this is not expected) This behaviour is present in current WebKit Nightly (5533.19.4,
r72783
) and Chrome Beta (8.0.552.210 beta), but not in current Safari (5533.19.4).
Attachments
Patch
(14.94 KB, patch)
2011-02-01 13:55 PST
,
Darin Adler
cfleizach
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Darin Adler
Comment 1
2010-11-30 12:20:48 PST
Seems likely I broke this with recent image map changes.
komoroske
Comment 2
2010-12-09 16:09:15 PST
A number of users have reported this in Chrome's user forums, too, using Chrome 8.0.552.215. See
http://www.menchies.com/locations.php
and
http://www.longtermcarelink.net/a7homecare.htm
for other examples.
Darin Adler
Comment 3
2011-01-19 11:08:40 PST
If someone else wants to fix this, they are welcome to. I won’t have time to work on it for a while. I’m keeping it assigned to me to remind myself about it.
Darin Adler
Comment 4
2011-01-19 11:08:56 PST
<
rdar://problem/8886118
>
Darin Adler
Comment 5
2011-01-31 17:34:04 PST
I am not so sure this has anything to do with my change. Seems to have something to do with focusing area elements. I did not realize we did that!
Darin Adler
Comment 6
2011-01-31 17:48:08 PST
I suspect this problem was introduced with
r53857
.
Darin Adler
Comment 7
2011-01-31 17:49:31 PST
The bad code seems to be HTMLAreaElement::dispatchBlurEvent.
chris fleizach
Comment 8
2011-01-31 18:00:04 PST
(In reply to
comment #7
)
> The bad code seems to be HTMLAreaElement::dispatchBlurEvent.
I only see this happen, if you first tab to the image map item, then click on it. the following click will then jump back to the image
chris fleizach
Comment 9
2011-01-31 18:02:19 PST
(In reply to
comment #8
)
> (In reply to
comment #7
) > > The bad code seems to be HTMLAreaElement::dispatchBlurEvent. >
It looks like imageElement->updateFocusAppearance(restorePreviousSelection); that is called from dispatchBlurEvent() -> updateFocusAppearance is causing the scroll back to occur. Since it's a blur event, it seems like it should not be scrolling on the update focus
Darin Adler
Comment 10
2011-02-01 09:27:20 PST
Yes, that’s right. The problem is that updateFocusAppearance is implemented and used incorrectly in HTMLMapElement. The job of that function, despite its misleading name, is to scroll to reveal the focused element, or something along those lines. HTMLMapElement tries to use it to trigger appropriate repainting of the image element. I’m working on a patch that redoes that map/image focus code to work with a correct model.
Darin Adler
Comment 11
2011-02-01 13:55:44 PST
Created
attachment 80820
[details]
Patch
chris fleizach
Comment 12
2011-02-01 14:17:25 PST
Comment on
attachment 80820
[details]
Patch r=me
Darin Adler
Comment 13
2011-02-01 14:49:24 PST
Committed
r77313
: <
http://trac.webkit.org/changeset/77313
>
gmmail2000-bugzilla
Comment 14
2011-03-14 11:29:01 PDT
(In reply to
comment #13
)
> Committed
r77313
: <
http://trac.webkit.org/changeset/77313
>
Will this patch be integrated in Chrome's new version, or what do I have to do to get my imagemap working in Chrome 10.0.648.133? Thanks for the answer.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug