Closed Bug 267512 Opened 20 years ago Closed 17 years ago

Child window with positioned iFrames not repainted properly (Linux only?)

Categories

(Firefox :: General, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mikol, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1

I implment and maintain a browser-based application for managing virtual
machines. The attached screenshots show a window from that application open in
Linux Mozilla 1.7, Linux Firefox 0.9.3 (Debian testing/unstable), Linux Firefox
1.0 RC1, Linux Firefox 0.10.1, Windows Firefox 1.0 RC1 and Windows Firefox
0.10.1. Note that in all browsers except Linux Firefox 1.0 RC1, the window is
painted as expected with a row of tabs at the top and the details for the
selected virtual machine below.

In the case of Linux Firefox 1.0 RC1, however, most of the window is not
repainted at all; instead "ghosts" of other windows positioned on top of the
browser window appear. A small square at the top left of the browser window and
a narrow vertical band on the right are the only areas painted properly.

Although I have not ruled out the possibility of a bug in the application rather
than the browser, the evidence suggests that the problem appeared in the browser
sometime after 0.10.1 for Linux. Other versions of Mozilla and Firefox (and
Internet Explorer) do not exhibit this problem.

Because I do not have a good, isolated test case, I am hoping that whoever
accepts this bug will be able to examine the relevant changes after 0.10.1 to
discover the source of the problem.

Please let me know if there is any additional information that could help track
down the problem.

Reproducible: Always
Steps to Reproduce:
Using Linux Firefox 1.0 RC1:

1. Log in to the VMware Management Interface for a VMware ESX Server 2.x system.
2. Click a virtual machine name to open the virtual machine properties window.

Actual Results:  
The virtual machine properties browser window is not [re]painted properly.

Expected Results:  
The virtual machine properties browser window should have been [re]painted properly.
This is a problem for me (and i KNOW a lot of others running Mozilla/Firefox
under Linux)... Mozilla 1.7.8 and Firefox 1.0.4 - same thing! No problems with
either on windows.
Mikol, have you tried to reproduce with minimal, static (x)html? that might be
something worth looking at?
Hi Thomas,

I just replied to a customer this morning about this very issue (is that a
coincidence? are you a VMware customer?).

Unfortunately, I don't have a minimal, static test case. And I'm not sure that I
can get to one. Although I stated in the original report that this problem is
always reproducible, I don't see it on my laptop, which is running a Debian env
that is remarkably similar to my workstation env. And there are other places in
our application that use a similar page structure (see the workaround below),
but don't exhibit the same broken behavior. So I am at a loss as to how to go
about generating a good test case.

But I do have a workaround for the problem. Some of the iframes in the offending
document had their initial visibility set to hidden:

<iframe style="visibility:hidden; position:absolute;"></iframe>

If instead they are placed offscreen until they are needed, the problem goes away.

<iframe style="position:absolute; top:-99999px; left:-99999px"></iframe>
Yes I am a VMware customer and this whole thing is kinda annoying.
It isn't just a problem with z-index of the iframes or something?
What moz are you running on debian... I've heard somebody say that this seems to
be a problem with mozillas that are not .0's. Seems that 1.6.0, 1.7.0 works and
1.7.5 etc. does not... I've not tested this myself!
Perhaps the version of you mozillas could help shed a little more light on this
thing?
Correction. This *is* reproducible on my laptop (Firefox 1.0.3).

Per comment #0, the problem was introduced sometime between Firefox 0.10.1 and
1.0RC1.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This appears to be working in firefox 1.5b1. Keep it working and we can close
the bug in my oppinion!
Assignee: bross2 → nobody
Based on comment 7, I'm going to close this bug as WORKSFORME. Thomas, if you're able to reproduce this, please reopen this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: