63730 - OBJECT content not rendered if show images is turned off

Status: RESOLVED WORKSFORME

(Core :: Graphics: Image Blocking, defect, P3)

Description

[HJ]

Used Build is 2000122220 on WinNT4 sp6

Description:
------------
If an object is not found, the content should get rendered, but it does not work
with Mozilla/Netscape6. This works in Opera, for example. User agent should
render the content as we can see at this W3C link:
http://www.w3.org/TR/html401/struct/objects.html#h-13.3.1

"If the user agent is not able to render the object for whatever reason
(configured not to, lack of resources, wrong architecture, etc.), it must try to
render its contents."

So that's why I belief that when a user agent is configured not to show images,
it should render the content inside the object tags.

Simple example:
---------------
<object data="menu.gif" type="image/gif">
[<a href="document1.html">Document (1)</a>]
[<a href="document2.html">Document (2)</a>]
</object>

This technique is used to create navigation menus for text/screen readers for
disabled people. So without this kind of support, users can't navigate the
visited site's. And thats why I think this is a major problem, at least for them.

Comment 1

[Asa Dotzler [:asa]]

H-J, not sure what you mean here.  Can you please attach or link to an
example/testcase and include necessary steps to reproduce buggy behavior.  Thanks.

Comment 2

[HJ]

Attachment: Screenshot of menu

Comment 3

[HJ]

Attachment: Screenshot of object content

Comment 4

[HJ]

Attachment: Screenshot of content in Opera 5.0 (image loading turned off)

Comment 5

[HJ]

For now, two screenshots how it looks in Opera 5.0. Attachment 21481 [details] shows a
graphical menu called menu.gif. Attachment 21483 [details] shows a non-graphical menu, the
one that must be used when graphics are blocked in preferences (attachment 21482 [details]
must be a wrong filetype or so, please forget that one).

Only by specifying a wrong file name i.e. 'menu.gof' instead of 'menu.gif' and
by removing the type="image/gif" attribute the content in between <object> tags
get rendered! It seems that the 'type=' attribute doesn't support all the types
specified in the latest W3C specs.

P.s. I will make a testcase soon.

Comment 6

[HJ]

Attachment: Testcase (set block image loading in preferences to see the difference)

Comment 7

[HJ]

Make sure to switch between: Edit/Preferences/Advanced/Images/Accept all images
 and: Edit/Preferences/Advanced/Images/Do not load any images

Comment 8

[Asa Dotzler [:asa]]

over to cookies

Comment 9

[Stephen P. Morse]

Possibly related to bug 47792.  Anyway, this is not a cookies bug.

Comment 10

[HJ]

Per W3C specs, user agents should render the object content, see my first comment.

Note for morse: I'm not asking for a item in the context menu! Mozilla should
render the content, as the specs say, it needs to do that, before calling it a
standards and compliant browser!

And people, Happy New Year, and keep up the good work.

Comment 11

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 12

[Terri Preston]

pavlov, can you tell me if this is still an issue?

Comment 13

[HJ]

I can't test this, without having a working pref setting to block images again.

Comment 14

[Greg K.]

See also bug 96976.

Comment 15

[Stuart Parmenter]

-> image blocking

Comment 16

[Mitchell Stoltz (not reading bugmail)]

Mass reassigning of Image manager bugs to [e-mail], and futuring.
Most of these bugs are enhancement requests or are otherwise low priority at
this time.

Comment 17

[Michael Newton]

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030228 Phoenix/0.5

The new HTML test suite at w3.org shows this bug (along with about 10 others) is
still occuring on new builds.
http://www.w3.org/MarkUp/Test/HTML401/current/tests/sec13_5-BF-01.html is the
test in question here.  Standards compliant browser you say?

Comment 18

[Mitchell Stoltz (not reading bugmail)]

The closest thing there is.

I confirm this problem still exists in Moz1.4. I'm not sure how important this
is to fix, though. Aaron, is this important for accessibility?

Comment 19

[Aaron Leventhal]

Mitch, it's not crucial for accessibilty in any way I can think of.

Comment 20

[Mitchell Stoltz (not reading bugmail)]

OK, then this can stay futured. Thanks Aaron.

Comment 21

[:Gavin Sharp [email: [e-mail]]]

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

Comment 22

[Gérard Talbot]

I was asked to implement an image map in the (almost) same way as described in
HTML 4.01 section 13.6.1.1 for developer.mozilla.org. After working on a demo
page, I realize this bug: alternate content of <object> as image is not rendered
when image download is disabled.

Here's the demo page:

http://www.gtalbot.org/Bugzilla/MapFirefoxToolbar.html

Like I said in that page, Lynx 2.8.5 (a text browser) and Opera 8 will render
the expected results. 

Comment 23

[Gérard Talbot]

"But of all the new elements, the OBJECT element (for including images, applets,
or any type of object) is the most important for specifying alternate content.
With it, authors may specify rich alternate content (i.e., that contains markup,
impossible with attribute values) at the same location they specify the object
to be included. When a browser cannot render the image, applet, etc. included by
an OBJECT element, it renders the OBJECT's (marked up) content instead.

One important application of this OBJECT feature involves client-side image
maps. In HTML 4.0, the content model of the MAP element has been expanded to
allow marked up anchor (A) elements that give the geometries of the map's active
regions. When placed inside of an OBJECT element, the textual version of the
image map will only be rendered if the graphical version cannot be. Thus,
authors may create graphical and non-graphical image maps at the same location
in their documents."
taken from
WAI Resource: HTML 4.0 Accessibility Improvements
http://www.w3.org/WAI/References/HTML4-access

adding access keyword

Comment 24

[Gérard Talbot]

My demo page is now at:

http://www.gtalbot.org/BugzillaSection/MapFirefoxToolbar.html

Comment 25

[Gérard Talbot]

When I try

http://www.gtalbot.org/BugzillaSection/MapFirefoxToolbar.html

with Seamonkey 1.5a rv:1.9a4pre build 2007040310 and with image download refused, I get the expected results. So, this should be fixed in Minefield (Firefox 3) trunk builds too.

Comment 26

[Gérard Talbot]

This bug has been fixed. 

When I try

http://www.gtalbot.org/BugzillaSection/MapFirefoxToolbar.html

with Seamonkey 1.5a rv:1.9a4pre build 2007040408 and with Minefield/3.0a4pre rv:1.9a4pre build Gecko/20070404 and with block image load
(Tools/Options.../Content category/Load images automatically checkbox unchecked; about:config for Blocking all images from loading is permissions.default.image), I get the expected results, that is: an unordered list of links pointing to respective toolbars of the non-loaded image.

Updating URL field

Resolving as WORKSFORME