March 11 Seamonkey builds, Mac 8.5/G3, Linux 5.2, optimized, viewer March 10 win98 optimized, viewer 1. Launch Seamonkey and load test case page: slip/projects/marvin/html/frameset_longdesc.html 2. These frames include longdesc attributes; it is unclear even per HTML 4.0 spec what the user should see when this attribute is used. • What should the user experience here when the longdesc attribute is used? Need clarification on this from engineering to determine A) if this is indeed a functional failure B) to refine test case.

Beth -- HOW we handle attributes is not a parser problem. It's core layout. Passing these on to Kipp.

I filed these all in one lump..hence why all were marked parser..will mark layout for this variety in future.

Chris owns the frameset code so reassigning...

Eric is working on frameset related DOM changes which will include longdesc, so I'm reassigning this to him to make sure that getting and setting this attribute works. However, what the viewport display does with this is not clear to me and maybe Troy has some insight, since it is related to what the viewport will need to do with the title attribute.

This is treated as the longdesc attribute on an img tag, which is to say it isn't yet. The attribute is stored in the content model correctly (as can be seen by dumping the content model. However, when the DOM methods are used to access it, an empty string is returned. After the document is loaded, the longdesc attribute can be set and retrieved through the DOM, but has no effect on either the content model or the display of the document. (This behaviour was observed at http://blueviper/frames/test.html)

Redistributing to M8...

Didn't make M8

This doesn't seem like a dogfood, beta, or final ship requirement to me, but more like an accessability enhancement. We are already storing the attribute in the content model, I think that should be enough for a while. Perhaps we should leave this up to the creator of an enhanced browser that embeds gecko to get then use the longdesc file as needed. Closing the bug open as remind. If anyone things this should be addressed now or before ship, please reopen and suggest how we should handle the longdesc attribute.

Reopening and moving to Future...

not my area, reassigning to vladimire

Bulk reassigning form bugs to Alex

The longdesc attribute is now supported with a img element. That procedure should similarly work with iframe/frame elements. Right clicking on a iframe or frame should display a popup menu that includes a View Frame info item. Selecting this menu item should open a dialog that includes the specified longdesc uri.

See http://bugzilla.mozilla.org/show_bug.cgi?id=1996

removing myself from the cc list

->

->Page Info I guess

Reporter, please try a newer build. This bug is getting quite old and will be marked invalid if some action does not occur shortly. -R

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

The previous URL http://slip/projects/marvin/html/frameset_longdesc.html is now "Not Found 404" Replacing with http://www.w3.org/WAI/UA/TS/html401/cp0203/0203-FRAME-LONGDESC-TEST.html

Shouldn't this be WONTFIX now that HTML5 obsoletes longdesc?

Since this is a 4 digit bug, I don't know that it matters whether HTML5 obsoletes longdesc here. But, note that for iframe HTML5 also obsoletes: frameborder, marginheight, marginwidth, and scrolling. I think if we don't have, or remove processing for those, then we should close this bug.

That's not quite right; it still requires that they be implemented by browsers (with the exception of "scrolling", no idea what that needs to do).

Removing QAwanted from this bug since it didn't come with any specific request and it was added 11 years ago. Please re-add if you need anything specific from QA.