Last modified: 2008-10-06 04:29:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8788 - ImageMap makes accompanying links unclickable
ImageMap makes accompanying links unclickable
Product: MediaWiki extensions
Classification: Unclassified
ImageMap (Other open bugs)
All All
: Normal normal with 3 votes (vote)
: ---
Assigned To: Tim Starling
Depends on:
  Show dependency treegraph
Reported: 2007-01-26 17:58 UTC by bdk
Modified: 2008-10-06 04:29 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description bdk 2007-01-26 17:58:00 UTC
Please have a look at the given URL and try to click all links on 
the right. The ones directly aside the image are not clickable. 

This also happens when <imagemap> is included in wikitables, 
or when it is accompanied by other simple <div>s with float, 
align or such. 

The only two browsers that allow clicking all links in this example 
(correctly, as expected) seem to be Opera 9.10 (on Mac) and IE7 (on WinXP). 
FireFox (1.5.x and 2.0x), Safari, Konqueror, Camino and others make 
some links unclickable.

ImageMap currently fails to be useful in many cases therefore, 
e.g. if you want to use imagemap near the top of the article 
about [[Australia]] so that it gets displayed aside the large infobox.

Thanks in advance for fixing :-)
Comment 1 Brion Vibber 2007-01-26 19:33:45 UTC
Table looks ok...

Testing in Firefox 2.0, the floating problem appears to be triggered by the
"position: relative" style on the enclosing <div>.

As far as I can tell, "position: relative" with no offset *should* act
identically to the default (implied "position: static"), which of course means
it shouldn't even be there... I think. :)

* with position: relative the links in the float don't work where they overlap
the <div>'s box (more easily visible if you set a border)

* without position:relative, the info link icon goes zipping around to the wrong
location, up in the previous paragraph or something.

Sounds like a bug shown by a workaround for another bug, or... something.

Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-26 19:49:18 UTC
position: relative with no offset acts as a bound for position: absolute elements inside it, for 
one.  For instance, <div style="position: relative;"><div style="position: absolute; left: 
1em;">Foo</div></div> will have "Foo" 1em from the left of the relative-positioned div, not the 
body.  That's why the info link goes somewhere else if you go to position: static.

The issue seems to be related to the fact that the containing block extends all the way to the 
edge of the page; the links only fail when the box overlaps them.  If we give an appropriate pixel 
width (which should be easy, since we know the pixel size of the contents), the problem disappears.
Comment 3 bdk 2007-01-26 20:39:18 UTC
Just to correct myself about what I meant with "wikitables" at #1 ...
Well, no "inclusion", obviously, but generally the same behaviour as for <div>s.
I was testing to much stuff today, so I mixed it up a bit, sorry ;-)
Comment 4 Michael Daly 2007-05-16 20:05:04 UTC
A fix for this bug is available in conjunction with that for bugs 8718 and 9126.
 See bug 9126 for info.
Comment 5 Siebrand Mazeland 2008-08-17 22:13:23 UTC
Assigned to extension developer
Comment 6 Tim Starling 2008-10-06 04:29:42 UTC
Fixed in r41720/r41725.

Note You need to log in before you can comment on or make changes to this bug.