514788 - Modifying iframe's location sometimes prevents window from repainting until browser looses focus

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Justin Lebar (not reading bugmail)]

Attachment: Testcase

STR:
* Visit attached page.  Load up another window (such as the error console) and resize the main window so that you can click between both without completely hiding either.
* Refresh the page until the iframe shows up as empty and "Completed." is not displayed below the iframe.
* Focus your other window.  The page should redraw, with "completed" printed below the iframe and a page-not-found message displayed in the iframe.

Expected results:
* The page should repaint when the iframe receives the error page and when we display "Completed."

Reproducible:
On my machine, this always happens with a debug build (changeset b1ccd18e73dd).  Happens much more rarely on a release build, but I made it happen once (while I was compiling) on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20090903 Minefield/3.7a1pre

Comment 1

[Heather Arthur [:harth]]

I'm seeing this in my extension, but I'm not modifying the iframe's location at all. I have a xul file that is more or less just:

<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">	
   <iframe src="mozmill.html" width="400px" height="700px"/>
</window>

when I open the xul file using window.open, and play around with the user interface in the iframe, the ui is not repainted whatsoever until I minimize it and bring it back up again, or I focus another window.

I'm on Firefox 3.5.5 w/ Ubuntu 9.04 and Gnome.

Comment 2

[Heather Arthur [:harth]]

This is fine in Firefox 3.0, but not in 3.5.5 to trunk.

Comment 3

[Heather Arthur [:harth]]

Attachment: Test extension

This is a test extension, to reproduce this bug:

1. Install extension
2. Click on red 'Open Iframe' menu item in the Tools menu
3. Click on the red box in the window that pops up.

Expected results:
the red box increases in width every time you click on it.

Actual results:
the red box does not increase in size when you click on it, only after minimizing or refocusing windows.


One thing I noticed is that this is fine when just browsing to chrome://iframerepaint/content/iframe.xul, this works, it's only when opening with window.open('chrome://iframerepaint/content/iframe.xul', '','chrome') that this occurs, and opening without 'chrome' also works.

Comment 4

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

Mats, could you look into this?

Comment 5

[Mats Palmgren (inactive)]

Regression range: 2009-02-24-02 -- 2009-02-25-02
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=69c86f3acc5a&tochange=8eba35e62d92
I have confirmed it's a regression from bug 298889 in a local debug build.

Comment 6

[Mats Palmgren (inactive)]

Attachment: wip1

Fwiw, this "fixes" the problem.  'aWidget' and all its child widgets have
GetTransparencyMode() == eTransparencyTransparent at this point so I don't
know what the real fix would be...

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Would take a safe fix with tests, don't think I'd block since we managed to ship Firefox 3.5 without it.

Comment 8

[Heather Arthur [:harth]]

Yeah, that's true. This is more for the addons, I'm sure some addons use iframes in their own windows, or will.

Mats, given the fix - is there a workaround a web developer or addon author could use temporarily?

Comment 9

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

Might be better to focus on getting rid of all child widgets rather than mess around with more hacks like bug 298889.

Comment 10

[Mats Palmgren (inactive)]

After reading all the comments in bug 298889 I agree.
(Is this bug Linux-only? -- maybe you were right in bug 298889
comment 62/65 after all.)

I can't think of a better fix, except making it conditional for GTK2 perhaps.
Still seems a bit risky.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is this fixed now given the widget removal that landed in compositor phase 1?

Comment 12

[Justin Lebar (not reading bugmail)]

Just tested Heather's extension in the latest nightly Gecko/20100124 Minefield/3.7a1pre, and I get the expected results.

Comment 13

[Mats Palmgren (inactive)]

I can still reproduce the problem, 20100126 trunk nightly, and local debug build.

Comment 14

[Justin Lebar (not reading bugmail)]

mats, harth, etc: Can you still reproduce this?

Comment 15

[Timothy Nikkel (:tnikkel)]

Does this still happen?

Comment 16

[Justin Lebar (not reading bugmail)]

Since nobody who has been able to reproduce this problem has commented here in a year, I'm closing this as WORKSFORME.

If you can still reproduce, please reopen!

Comment 17

[Mats Palmgren (inactive)]

Works for me too, 2011-01-14 nightly and local DEBUG builds on Linux64.