Position Issue with iwModal and WebApplication Dialogs

[takyon_dg]

Hi folks, so there appears to be differences in terms of display position of iwModal depending on the device/browser.

For example for iwModal: Desktop / Microsoft Edge, regardless of the size of the window.. it's centered. Android / Chrome, it acts as if the screen is about twice as wide and high as it is designed... Android / Edge behaves the same (sure, it's Chrome), but Android / FireFox centers the modal display properly.

For ShowConfirm or ShowPrompt, I haven't found a browser that fits this in the current view, they always seem to be positioned to the right and much wider than the display, requiring me to scroll over (no good).

I've tried things like iwModal.WindowLeft/Top/Width/Height for iwModal and it doesn't seem to matter. I've tried setting formwidth/height for WebApplication, that doesn't seem to do anything for this.

Tried to size the form only to the actual resolution of the display I'm testing on at design (as at design, it's rather wide so I can see all the display elements, including the modal components I use), no change.

It would seem to suggest Intraweb or the browser thinks the display for the popups is much larger than it is, but I suspect this is something the browser is reporting. Maybe this is fixed in newer versions of IW, but I'm currently stuck on 14. I wonder if anyone either:

a) knows where I can fix the dimensions for chrome in it's settings (I've looked, nothing is jumping out to me) 
b) some kind of scripted override to make these show up center (and within the dimensions) of the display.
c) or anything else you can think of for me to try.

Thanks.

[Alexandre Machado]

There were several changes/fixes in the core code involved in modal windows display. I'll test this with the latest version but I'm not sure something can be backported to IW 14. Any particular reason why you are stuck in version 14? It's almost 10 years old (which equals a century in the web) but most applications can be migrated to the latest IW 16 with very little changes...

[takyon_dg]

Well, I managed to circumvent the issue with the ShowConfirm/ShowPrompt by overriding the CSS for positioning with !important... there's some fixed <style> tag attached to the iwNotify ID in the html body. Ultimately the problem seems to be how the browser see's it's size (or calculates the % into a coordinate) because the html IW creates is simply width and height in percentages which should (and do in other contexts) draw properly. Interestingly if I look at JS properties like clientWidth or viewport width, they report properly. So I don't think this is IW's issue, other than I couldn't find a way to SET the left and right position at design time and have it be reflected in the browser...beyond adding in raw header html. Anyhow, that ones sorted.

As to the modal window, I'm not sure yet if I can add header script to get past the issue there, playing around in browser dev tools trying to figure out how/where this positioning is happening, I tried a similar strategy but the way it redrew the modal window was not what was expected.

As to the version, we're too far into QA to switch up a core component like this at this time (nor am I convinced it actually would work if this is a browser issue). So we need to find a workaround for what we have at the moment. Otherwise, everything else is working great, this is more-or-less the last thing in terms of drawing anomalies we need to address.

[takyon_dg]

So if I can get a "style=" tag into the iw-dlg-window class='iw-dlg-windowCSS' line with a fixed left and top position, this will work (based on runtime editing using browser dev tools).

Now, what about the OnHTMLTag event? If I do an ATag.AddStringParam('style', 'left: 10px; right: 10px'); nothing seems to happen on rendering the modal pop-up Async. This tag doesn't show up anywhere in the elements tab in dev tools (And it doesn't change it's incorrect position).

What am I missing? Or is there some documentation somewhere on how to use OnHTMLEvent and TIWHTMLTag?

[takyon_dg]

I think I've figured out what's going on. So even though I set the width of the form to the device dimensions, with Chrome on Android (or at least this version), if you have any components drawn (even if invisible, and used for modal only) outside the device/window/browser dimensions, it acts as if the window is larger than it's visible components (this applies even if you, at design-time, change the width of the form to the browser window size.

Once I moved all of my invisible controls within the window size, the pop-up ended up center of the window. Looks like this works programmatically moving them in FormCreate too.

[Alexandre Machado]

We have found and fixed the issue.

The behavior of mobile Chrome browsers have changed recently (not exactly sure when, though).

The thing is that Chrome will report wrong sizes (CSS sizes, not pixel sizes) of the page when IW starts, unless a viewport tag is provided. Firefox does it "right" and report the correct sizes regardless of the viewport tag. This causes IW to start the application with wrong form sizes, causing the effect that you mentioned.

You can force it to behave correctly using this viewport tag in your ServerController.MobileOptions.ViewportTag:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

This fixes it.

Anyway, we are releasing a new update which will force the correct viewport tag regardless of your ServerController settings.

Cheers,

[takyon_dg]

Thanks. Though I'm almost certain I saw that viewport tag present on mobile.

Well actually it was this (but this was in IW 14.2.3):

<meta name="viewport" content="width=device-width, initial-scale=1">

The only difference there is the 1 vs 1.0

[Alexandre Machado]

I'm absolutely sure that it works in latest version, adding

ServerController.MobileOptions.ViewportTag = <meta name="viewport" content="width=device-width, initial-scale=1">

(1 or 1.0 doesn't make any difference)


I'm not testing 14.2.3 (it has been discontinued 12 years ago)

[Alexandre Machado]

The new update IW 16.1.7 (just released) will fix this issue in Chrome mobile and other mobile browsers.

Cheers,