FF18 blanks form fields once a popup window closes
Once updated to FF18 I notice odd behavior. Once the popup window disappears (window.close()) all of the forms on the web page blank out. Even things like drop-down controls are replaced with a plain white box.
I can get them back by changing focus to another program on my PC, or by switching to another tab and back again. I can even have the "fun" of making the mouse visit each control in turn, redisplaying the form fields individually.
Jolly fun perhaps, but I'm on tech support for my company and this behavior makes my firm look bad. If I can't get a reasonable answer to this I have to go about saying "FF18 isn't recommended, try browser X".
Any clues out there? Thanks,
Additional System Details
- Shockwave Flash 11.5 r502
- Adobe PDF Plug-In For Firefox and Netscape 11.0.01
- NPRuntime Script Plug-in Library for Java(TM) Deploy
- The plug-in allows you to open and edit files using Microsoft Office applications
- Office Authorization plug-in for NPAPI browsers
- Npdsplay dll
- User Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0
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?
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.
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.
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.
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.
Modified by JeromeMrozak