125763 - toggling visibility on IFrames doesn't work on Mac

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Henry Krempel]

The URL above has a simple example of an IFrame that is shown/hidden by setting
the visibility.

Depending on where the IFrame is positioned, the refresh of the display is
different when you show/hide the Iframe. Sometimes the IFrame doesn't show up,
sometimes it never goes away, sometimes it partially goes away, etc.

It never works correctly, though.

I checked this on 0.9.8+ (today's mozilla) and on NS6.2

Seems to work OK on a recent windows version I checked.

Comment 1

[Bob Clary [:bc] (inactive)]

I can click on the link to display the iframe but can not get the iframe to hide
by clicking on the link again in 2002 02 25 03/win2k trunk.

Note this is similar to http://mozilla-evangelism.bclary.com/evang500/test.html
where if you click on Start it will create an IFRAME dynamically, set it's
visibility to hidden and append it to the body element's children. The iframe
was hidden in 0.9.8 but is now visible although the scroll bar does not work. I
think this is a recent regression on windows at least.

bz, what do you think?

Comment 2

[Boris Zbarsky [:bzbarsky]]

I think it sounds like something roc should look at....

Comment 3

[Jaime Rodriguez, Jr.]

Taking the initiative and re-assigning to Heikki for now, because no one has
done anything with this bug in over 2 weeks. If this is not one for your team,
pls reassign to the appropriate group.

--> Heikki

Comment 4

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

Johnny, is this at all related to your iframe patch?

Comment 5

[Johnny Stenback (:jst)]

No, it's not directly related to my iframe bug (bug 52334), but if that bug was
fixed then people wouldn't need to have iframes with visibility: hidden; In
stead they could have iframes with display: none; which is cheaper and what the
users want in the first place.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this just a transient painting bug? Or if you force the window to completely
refresh, does it still paint incorrectly?

Comment 7

[Kirk Parsons]

Johnny, not to be demanding but, I think that what we users want is *both*
display:none and visibility:hidden.

Robert, the reporter is out on vacation until 4/9.  His test URL is down right
now, but I'm looking into it to see if I can get it back up and get an answer to
your question. 

Comment 8

[Henry Krempel]

I would say that developers do need both visibility and display style settings.
 visibility is useful for hiding elements that don't effect the flow (absolute
positioning), display is useful for hiding elements that are in the flow
(relative positioning).

A Tree control is an example of something that wants to show elements and flow
all the following elements down.

This is a transient painting bug, if you resize the window, the display is fine.

Comment 9

[Jaime Rodriguez, Jr.]

This is one of the DIG's top bugs, and we should get it fixed on the 1.0 branch
asap.

Comment 10

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

Totally forgot I had this one. Changing status to NEW although I have not
confirmed this (just so this won't get lost again), and reassigning to jst for
investigation. Has anyone seen this on Mac OS X?

Comment 11

[Johnny Stenback (:jst)]

The URL in this bug is not reachable, I need a testcase to start looking into
this. Henry? Kirk? Please help.

Comment 12

[Henry Krempel]

Attachment: showing and hiding Iframes on the Mac

Comment 13

[Johnny Stenback (:jst)]

Hmm, not sure how to proceed on this one. I have little to none experience with
Mac widget code, and it seems like the problem would be there since none of the
other code that should matter in this case is platform specific. Over to sfraser
in hope that he could investigate this further. Also, other mac people, please
step up if you think you could help out here, this is topembed+, [DIGBug] n' so
on, it's important...

Comment 14

[Johnny Stenback (:jst)]

Oh, I did confirm that this is indeed a problem on the mac, and it's only on the
mac. Works fine on Win32 and Linux.

Comment 15

[Johnny Stenback (:jst)]

Ok, since Simon is on sabbatical I'm handing this over to Pinkerton for furhter
investigation...

Comment 16

[Mike Pinkerton (not reading bugmail)]

-> saari

Comment 17

[saari (gone)]

The iframe is correctly showing or hiding, but the paint is not occuring. So it
is a damaged region/invalidate/paint bug.

Comment 18

[Kevin McCluskey (gone)]

CC'ing jkeiser since he fixed a similar cross-platform bug recently - related to
iframe borders not being painted after toggling visibility.

Comment 19

[John Keiser (jkeiser)]

With an OS X branch build from the 19th, this bug does not appear. 
Specifically, when I click the show / hide toggle, it always toggles from show
to hide to show to hide.

Comment 20

[John Keiser (jkeiser)]

OS 9 branch from the 24th, no problem either.  It's white instead of gray in
that case, but it is painting.  These are both Netscape builds, BTW, which
should be identical in this respect.

Comment 21

[saari (gone)]

Oh hey, it works in ProjectX too. Neat, should have tested a more recent build. WFM

Comment 22

[Jaime Rodriguez, Jr.]

removing  [adt1 RTM]and [ETA 06/24], as this is now WFM.

gregwhite - let us know, if this doesn't work for the DIG. thanks!

Comment 23

[Greg White]

This sounds fine from what I read.  I am checking with Henry Krempel who is the
submitter and is in DIG.

Comment 24

[Henry Krempel]

Tested on: macos/10.x/ppc/2002-07-09-05-1.0/

looks like it works fine