When you close the pop-up, does it make any difference whether you are sending an update to the opener page or just canceling?

In case it's an artifact of the hardware graphics acceleration feature, could you try disabling it? You usually need to restart Firefox in order for this to take effect, so save all work first (e.g., mail you are composing, online documents you're editing, etc.).

orange Firefox button or classic Tools menu > Options > Advanced

On the "General" mini-tab, uncheck the box for "Use hardware acceleration when available"

If you restart Firefox, is the issue improved at all?

The popup is closed by Javascript control. It notices that it has only one item in its list, fills the appropriate fields in the main web form and then calls window.close(). If the user closes/cancels an opening page then there were no updates and no blanking of the page.

Our page *is* complex, and there are likely a number of DIV-type dialogs also being briefly called -- my colleague *loves* calling Ajax services. So I can't guarantee that it is window.open() exclusively.

Although it *could* be an artifact of hardware, I'd hate to support our users by telling them to monkey with their advanced settings.

My work day is about done now. I'll have a fuller answer on the second part of your query tomorrow.

I've attached a sample of what I see in the browser. All blank, except for some fields I dragged a mouse over. Note that the drop-down controls also get blanked out.

This AM I tried the "adjust FF" idea, not using acceleration. That didn't do anything for me.

I've been debugging this all day. I have the problem isolated to one Javascript line in my code. A little background is needed.

We create a lot of DIV dialogs in our web site. Although features of them are managed through a code base we call HaloDialogManager, it all amounts to bookkeeping for 1) document.createElement("div"), 2) fill the DIV, 3) use the dialog through document.body.appendChild().

There is one special DIV we call "modalDiv". That is greyed-out, and made very large, to be our modal layer. Through bookkeeping, when we have no more modal dialogs we also remove the modal DIV.

We have a place where we ask if we should show or hide the modal layer. In the problem condition we are hiding the modal div, after which we will delete it.

I've traced down my problem to this line:

       HaloDialogManager.modalDiv.style.display = "none";

That is, the DIV stored in .modalDiv gets a new display type. In context, we do this:

       HaloDialogManager.modalDiv.style.visibility = "hidden";
       HaloDialogManager.modalDiv.style.display = "none";

This has worked fine until now. But now, at anywhere from 0% to 50% of the time, running (display = 'none') blanks the form. Note that it doesn't happen every time, just lots of it. Once it is made to happen it continues to happen.

Now that I've described it, can you explain this? Thanks for help, Jerome.

Another thing about the problem -- If I single-step through the code the problem doesn't occur. Once in the neighborhood, I found the offending line by setting a single breakpoint, each line in turn. The line I mentioned is the one just prior to the final breakpoint I tried.

You shouldn't have to do anything for Firefox to repaint the content that was hidden behind the higher "layer" after that layer is removed. Off the top of my head, I can't think of any reason that it would work fine several times in a row and then stop working.

You mentioned that if you switch away from Firefox and back again the form field values do repaint. But then the problem immediately repeats after the next dialog display?

Same result using the zoom-unzoom method to force a repaint (Ctrl++ then Ctrl+-)?

Are any iframes or plugins behind the modalDiv?

Single-stepping (or using alert dialogs) can mask timing problems by stretching out the amount of time available for a task to be completed. But I don't know whether that is relevant in this case.

Hmmm...

Does the problem repeat after the next dialog display? Yes, it does. I can switch away and then back again and the fields are properly displayed. Click on the "Search" again and, at the end of the process, the fields are blank.

Same result with various zooms? The problem changes -- it can be harder after a Ctrl + or Ctrl - to get the problem to recur. However, I've found no setting of Ctrl + or Ctrl - or Ctrl 0, even multiples, where I'm guaranteed to not have the field blanking not occur again. Interesting that the zoom has any effect at all.

Any iframes or plugins? I don't use iframes. My plugin list is an attached image.

Per your suggestion, I removed the offending "display = none" line (and its matching "display = block" line). The result is that it is very hard to make the "blank fields" problem recur. I try the "Search" routine maybe 12 times in a row and get no blank fields. I will continue to examine that approach and why we are using both "display=none|block" and "visibility=hidden|visible" in this section.

I will also examine rolling back some Microsoft updates that were installed in this time frame. I'll be looking at KB2799494, KB2778344, KB2780091 and KB2802968. The FF18 problems might be side-effects of these updates.

Changing the Microsoft updates didn't do anything constructive with this problem. Removing the updates one-by-one, then testing the result in FF, didn't yield a situation where the "blank fields" problem didn't exist. The MS updates aren't affecting the way FF acts.

I will continue to investigate not using (display=none|block). I do think that adapting our code to get around "on again - off again" FF behavior is suboptimal.

Hi Jerome, thank you for the detailed updates. If you do not an acceptable solution, you may want to file a bug for this since superimposing and removing an element from in front of another element should not affect form fields differently than text. It would be helpful to have a simplified demonstration of the problem so the developers can replicate the issue.

https://bugzilla.mozilla.org/

Firefox 19 was released last night. It doesn't appear to have the same behavior problems that 18 did. Since I have a reasonable solution here (don't use FF 18, use FF 19) I'll be dropping this conversation.

Thanks for helping.