Resized event all wrong in Xojo Web

I just discovered a very strange thing with the Resized event in WebPages.

I have a WebPage1 which contains code in the Resized event to display WebPage1Portrait if self.width < self.height.

In a button I have code to display a third page, let us call it WebPage3. That page does not have anything in its Resized event to display new pages.

When I resize it, the event in WebPage1 is triggered !

I thought I needed to close WebPage1 to avoid that, so I closed it in the button that displays WebPage3. Then resize stops working in WebPage3.

This looks either like a bug, or like some sort of child inheritance in the instantiation of the WebPage.

I shall prepare a bug report tomorrow.

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

feedback://showreport?report_id=39536

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.

After that, Resized never fires again.

The problem does not exist with Palette dialogs.

feedback://showreport?report_id=39623

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.

I understand, now. Yes, the dark overlay…

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 ?

Shouldn’t they?

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.

I understand.

I started the thread with it. The case has a simple project attached to it demonstrating the issue. Of course no resizing library in there :wink:

feedback://showreport?report_id=39536

Thank you for your attention to this.

Oops.

Seems closing a page is not possible. Xojo complains design time objects cannot be closed.

Nevertheless, if I go WebPage1.Close I get that warning, but yet the Resized event for that page stops firing. And the current page still fires.

Sorry, what I was reporting does not happen. Please disregard. Thank you.

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.

Indeed Width and Height should be reported correctly.