98166 - IFrames or Object w/ text/html with "position: fixed" vanishes after clicking it or scrollbar of containing page

Status: RESOLVED WORKSFORME

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Description

[Jens-Erik Weber]

An object of type text/html with style="position: fixed" is rendered correctly
(finally, congratulations!!! :-) - see bug #678) on Windows 2000, not on Linux
(there you see only the border), but as soon as you click the scrollbar of the
containing document or into the object (link, scrollbar or anywhere else), it
vanishes; the border (coloured for testing purposes) remains.

With "positon: absolute" the problem does not occur.

It would be so useful for navigation to have a text/html object with position:
fixed, because you only have to maintain one navigation document for the whole
site and with position: fixed it can replace frames, that are not in the strict
DTDs, so please fix it!

Comment 1

[Cormac F]

Attachment: File containing object tag

Comment 2

[Cormac F]

Attachment: Page that is loaded into object tag

Comment 3

[Cormac F]

Confirmed WinNT build:2001090403
Couldn't find a similar dupe.

Posted simplified test case - you need to download both html files and place
them in the same directory

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: HTML containing object tag and pointing to the "included" file in bugzilla (no need to download)

Comment 5

[Cormac F]

The Object area isn't removed from the page if you click on it i.e. open two
browser windows, click on the object area, then switch to the other window and
back again - the object area should have reappeared. 

Comment 6

[Christopher Hoess (gone)]

Is there a separate bug for these objects failing to work under Linux?

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.

Comment 8

[Markus Gerstel]

Has already be confirmed - why still unconfirmed ?

Comment 9

[Peter Lubczynski]

mine...but could be a dup

Comment 10

[Jens-Erik Weber]

In the latest nightly builds text/html objects with position: fixed don't show
up at all (only the borders), not even before a click. And iframes with
position: fixed show the same behaviour; they worked perfectly (at least) until
Mozilla 0.9.4 milestone release. Now e.g. in
<http://www2.student.uni-augsburg.de/~aegee/> the included navigation doesn't
work anymore. iframes and objects with position: absolute still work perfectly
(I've included a link in my test page).

Comment 11

[Peter Lubczynski]

Kevin, is this a dup of an IFRAME absolute-positioing issue?

Comment 12

[[not reading bugmail]]

page: http://pc00ep5.physik.uni-augsburg.de/test2.html

absolute shows content.. 

page: http://pc00ep5.physik.uni-augsburg.de/test.html

fixed does not..

2001-11-01-03 W2K.

Comment 13

[Peter Lubczynski]

-->HTMLFrames

Comment 14

[Kevin McCluskey (gone)]

Bulk re-assigning all of Eric's HTMLFrame bugs to John.

Comment 15

[Boris Zbarsky [:bzbarsky]]

The testcases work for me, with a current linux build.  Is this still a problem?

Comment 16

[Boris Zbarsky [:bzbarsky]]

apparently not.  Feel free to reopen if this is still an issue.

Comment 17

[Scott A. Colcord]

Is WORKSFORME the correct resolution?  WORKSFORME is defined as a failure to
reproduce the bug, but in this case, the original bug was well-confirmed.  It
seems like it was FIXED, although most likely as a side effect of another fix. 
Unfortunately, it seems like VERIFY-ing this will require QA (or a volunteer) to
test old versions to find when this bug went away, and try to link it to the fix
responsible.

Comment 18

[Boris Zbarsky [:bzbarsky]]

FIXED means you say what fixed it.  Failing that knowledge, worksforme is
used... (because no one has the time to hunt down the side-effect that fixed this).