Last Comment Bug 209424 - (bearded-imagemap) undisplayed <object> with usemap gets link-image border anyway
(bearded-imagemap)
: undisplayed <object> with usemap gets link-image border anyway
Status: RESOLVED FIXED
: testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: -- minor with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.robinlionheart.com/stds/ht...
Depends on: moz-broken
Blocks: html4.01 robin's
  Show dependency treegraph
 
Reported: 2003-06-14 14:49 PDT by Robin Lionheart
Modified: 2014-04-26 02:24 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot of bug (14.14 KB, image/png)
2003-06-14 14:51 PDT, Robin Lionheart
no flags Details
simplified testcase (1004 bytes, text/html; charset=iso-8859-1)
2003-06-14 15:11 PDT, David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch)
no flags Details

Description Robin Lionheart 2003-06-14 14:49:24 PDT
On my Objects test page, I combine cascading object content types with image maps.

Mozilla renders one of the alternate markup images and handles the image map
fine, but, it produced an extra border around the lower corners and bottom side
of the image, giving it a sort of beard. It's easier to see than to describe.
See attached screen shot.
Comment 1 Robin Lionheart 2003-06-14 14:51:28 PDT
Created attachment 125659 [details]
Screenshot of bug
Comment 2 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2003-06-14 15:03:27 PDT
We're displaying the PNG, and the extra border is the border you get when you
treat the OBJECT for the TIFF as an inline element and put a border on it.

This is because of the following rule in html.css.

*|*:-moz-any-link img, img[usemap], object[usemap] {
  border: 2px solid;
}

We need a way of preventing this rule from applying to objects that are ignored.
Comment 3 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2003-06-14 15:04:50 PDT
.
Comment 4 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2003-06-14 15:11:31 PDT
Created attachment 125660 [details]
simplified testcase

The relevant part of http://www.robinlionheart.com/stds/html4/objects.html ,
slightly simplified.
Comment 5 Will Holcomb 2003-11-30 09:12:51 PST
This bug is also visible in:
  http://odin.himinbi.org/covers/

The page contains svg images in object tags with pngs (also in object tags)
nested inside. The svgs are 400x400, but the pngs are various sizes. There are
borders around all the objects in the page and you can see the 400x400 borders
around the non rendered svgs through some of the ongs (which have transparent
backgrounds).
Comment 6 Boris Zbarsky [:bz] 2005-09-18 23:24:56 PDT
So now that bug 11011 is fixed, we could fix this, somewhat.  I'm considering
something like this:

*|*:-moz-any-link
img:not(:-moz-broken):not(:-moz-user-disabled):not(:-moz-suppressed),
img:not(:-moz-broken):not(:-moz-user-disabled):not(:-moz-suppressed)[usemap],
object:not(:-moz-broken):not(:-moz-user-disabled):not(:-moz-suppressed)[usemap] {
  border: 2px solid;
}

This will also not show the border on broken images that we're showing a
placeholder for, though.  I don't see an obvious way around that, unfortunately.
Comment 7 Mardeg 2012-02-09 22:52:14 PST
This bug was last visible in Firefox 3.6 and is WORKSFORME since the switch to the html5 engine (bug 373864), but should it be marked as that or FIXED while the dependant bugs are about html4.01 and are still open?
Comment 8 John Schoenick [:johns] 2012-04-10 17:28:31 PDT
Fixed in HTML5 parser, closing
Comment 9 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2012-04-10 17:32:47 PDT
How did the HTML5 parser fix this?  I'd think it's more likely fixed by the complete removal of the border style.
Comment 10 John Schoenick [:johns] 2012-04-10 17:44:35 PDT
@dbaron - I'm rounding up old <object> bugs and resolved this based on Mardeg's comment and works-for-me.  Looking at this more, you're right, this was fixed by removing the faulty rule entirely.

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