39536 - Resized event from the first WebPage displayed fires when a WebPage showed from it is resized
OS: OS X 10.10.3 and Windows 8.1
Xojo: Xojo 2015r2.2
Steps: This is a rather unusual bug I would have never expected. It was very surprised when I found it.
The attached project contains
WebPage1
WebPage1.Portrait
WebPage3
WebPage 4
On WebPage1, there is a button which does
WebPage3.Show
In the Resized event of each page, is this code, indicating the page where the Resized event fired (WebPage1 here) :
System.debuglog "WebPage1 Resized - PageCount : "+Str(Session.PageCount-1)
When I launch the program, WebPage1 its Resized fires.
When I click the button which shows WebPage3, and WebPage3 displays, its resized event fires.
When I resize WebPage3, First WebPage1 Resized fires, then WebPage3 Resized event.
Each WebPage opened fires after all the previous WebPages Resized events have fired.
This is very unsettling.
Expected Result:
Only the displayed WebPage Resized event fires
Actual Result:
All “parent” WebPages Resized event fire in succession
Workarounds:
Keep track of the current page each time Show is used
I am still tracking the strange bug that makes all previously opened WebPages Resized event fire when the browser window is resized on the last one. And that if they are closed the Resized event of the current page no longer fires.
I installed RubberViewsWE on a WebDialog and was expecting the same phenomenon to take place, but no, web dialogs Resized event does not trigger the Resized for the previously opened WebPages.
I was wondering why RubberViewsWE did not work quite right with dialogs, until I realized that very simply, not only width and height are wrong on the first resized, but then it stops entirely working on Sheet and Modal dialogs. I have applied a workaround, but Resized seems definitely a problem in Xojo Web !
39623 - Resized event wrong size and stops firing on WebDialogs
Status: Needs Review Rank: Not Ranked Product: Xojo Category: Compiler
Michel Bujardet Today at 6:33 PM
OS: OS X 10.10.3
Xojo: Xojo 2015r2.2
Steps: Run the attached project which demonstrates the issue.
Sheet dialogs and Modal dialogs Resized event does not work properly.
Upon opening, it correctly reports the design size of the dialog.
When the user resizes it the first time around, Resized fires but self.width and self.height instead of being those of the dialog are those of the browser window.
Yeah, this is a known bug. The dialog control includes that dark overlay thing and so the browser includes that in the measurement. Add to that (another of your bug reports) the fact that the Resized event fires before the width and height properties get updated, which has turned out to be a Chicken vs Egg problem.
It is a lot of fun for a program that needs to know the size of a dialog in order to keep the layout consistent.
I have been able to go around that in JavaScript by using onMouseDown and onMouseOut where I get the size of the dialog itself and send it back through WebSDK.
About the fact that all parent web pages fire Resized at the same time as the child which is on the screen, any thought ?
I may not be describing that correctly with Parent and child. Sorry.
Let us say I have a page A which shows a page B through a button. In practice, when page B is displayed, A no longer displays.
Yet, if the browser window is changed, Resized fires in both B (currently on screen) and A (not displayed). This goes on for as many pages as there maybe. If I have five pages that open new ones, the very first one will fire Resized if only the last one is on screen.
I was not expecting that behavior. Even more surprising, in the example with A and B, if I close A while B is on display, B’s Resized event stops firing altogether. I could imagine that once pages are showed they still remain in memory to display faster, but why should they fire Resized, and worse, why should Resized disappear from a page displayed subsequently if one closes one opened before ?
I filed 39536 with a project demonstrating all that.
All that surfaced when I added page selection based on browser window shape in Resized. Something like
If self.width < self.height then
PortraitPage.Show
end if
That works quite fine on the first page displayed. But if several other pages have been shown after the first one, and the user rotates the device or makes the window Portrait, the vertical version of the first page will show instead of the current page. I do not think this is right. I had to implement special code to track which page was currently on screen, so I could dismiss the non displayed pages event.
Well, the reason Page A continues to fire is that it’s still there. It’s still in existence on the browser and if we DONT Fire resize events and the user closes Page B, controls manipulated in the resized event would not be where they need to be. This behavior is unlikely to change.
As for the Redized event of Page B no longer firing if page A is closed, please file a simple bug report so I can see this in action, preferably without your resizing library if you can reproduce it without.
For what its worth and from a design standpoint I find WebPage’s to be cumbersome and limited. I typically only have a couple that exist and everything else is dynamically embedded as WebContainers. Whenever I do create something as a WebPage and not a WebContainer it ends coming back to bite me later so now I strictly avoid it from the start.
I’ve also had a plethora of issues with WebDialogs and their dimensions. You’ll notice that if you try to embed a container it will be relative to the gray area - which can both be a blessing and a curse. But having to get the true dimensions via a hack-job is less than ideal.
As a workaround until the 2.0 WebFramework can get here it would be nice if they added “InnerWidth/Height/Top/Left” properties to WebDialogs accompanied by an helper WebDialog.EmbedContainerWithin() method. This last method could also be added by anyone as a utility method that uses EmbedWithin with some javascript followup methods.
I’ve also had issues with resizing WebDialogs where they continue to grow off into infinity… all in all WebDialog are not fun and seriously need some attention.
