Firefox >=14 sometimes does not fully show image on pan on Ajax viewer (redraw issue)

[gabrimonfa]

Mapguide 2.2 & 2.4

Sometimes (particularly doing a pan moving up the map) Firefox do not completely show the image that appears truncated or completely invisible.

It is a redrawing issue because the image appears to be received correctly (through Firebug or its console) and moving around the window or doing other things that force a repaint solve the issue, aka the image is displayed fully and correctly.

This issue is very annoying for users (it happens randomly) and is probably due to the two (or three) <img> that are updated at each pan, namely the map and the selection. It is also difficult to produce a simple test case for opening a bug against Firefox, since I think we are triggering some Firefox bug here with all that <img> manipulations.

This is probably a Firefox bug, but a workaround on Mapguide side is welcome

[gabrimonfa]

I've found a workaround for this problem.

Let's see function RequestMapImage (in viewerfiles/ajaxmappane.templ).

On map request, if we are on all browser except safari and chrome the innerHtml of div#overlay is modified (on opera a hack is then used to force redraw the content).

On safari and chrome we instead use a sort of double buffering, loading images alternatively on two different <img> and toggling their visibility. This is used because otherwise the browser would show briefly, after a pan, the image in the original position and then the moved one, which is visually very annoying (it is easy to see that for example if

chrome is used and the "

chrome" is removed in the IF clause).

My workaround is passing Firefox in the list of browser which adopt the two images and swaps between them at each image change.

- if(safari || chrome)
- {
-    LoadAlternateImage(url, reqId);
-}

+ if(safari || chrome || firefox)
+ {
+    LoadAlternateImage(url, reqId);
+}

This simple update seems to solve the issue, because swapping the image force Firefox to redraw map content.

[jng]

I can confirm patching the call to LoadAlternateImage() as described fixes this problem. Does the same fix need to be applied for calls to LoadAlternateSelectionImage() as well?

[gabrimonfa]

No, from my tests there is no need to call LoadAlternateSelectionImage(), selection is working correctly as is

[jng]

Fixed 2.4 (r6979) and trunk (r6980). Thanks for the patch.