diff options
author | Leon Scroggins <scroggo@google.com> | 2009-04-22 11:47:59 -0400 |
---|---|---|
committer | Leon Scroggins <scroggo@google.com> | 2009-04-23 14:04:08 -0400 |
commit | 805e9335952da33d9af0f1ec5c07bc5568feb312 (patch) | |
tree | bb2d56cdf72101f5f44027a29d53654a99f7c035 /WebCore/platform/graphics/IntPoint.h | |
parent | 1b6b93a1770ab3293721e45886c8c1ae9f914163 (diff) | |
download | external_webkit-805e9335952da33d9af0f1ec5c07bc5568feb312.zip external_webkit-805e9335952da33d9af0f1ec5c07bc5568feb312.tar.gz external_webkit-805e9335952da33d9af0f1ec5c07bc5568feb312.tar.bz2 |
Fix some unexpected cases of image maps.
Fix for buganizer issue 1800613: Image map not accessible. We were attempting to cache associtations of <area> elements to their RenderImages so we would not have to search for them. However, we were storing them in CacheBuilder. When we search for them, we search in the <area> element's frame, even though when we built the cache, we stored it in the main frame. Another issue arose on a page where <area> elements show up before their RenderImages. In this case, we were storing an empty rectangle for the bounds, and caching the associations afterwards, when it was too late. In order to clean up/simplify things, while fixing both bugs, I have changed validNode into a static function which takes the starting Frame as a parameter. Any time we need to find the rectangle of an <area> element, we have to traverse the DOM to find its associated RenderImage. This may be slower, but it will always get the correct answer. In the future, we may need to investigate a universal location for caching the associations for better performance.
Diffstat (limited to 'WebCore/platform/graphics/IntPoint.h')
0 files changed, 0 insertions, 0 deletions