What has changed between 2020r21 and 2021r1 for webpage.show?

Targets Web
#1

Hi everyone,

I have a small project that shows a webpage using mywebpage.show in a button.
works fine in 2020r21, and seems to hang (or quit without really quitting) in 2021r1
this page has some websdkuicontrols on it

any idea what can cause this ?

thanks.

#2

Probably a 2021r1 bug, or presence of some hack that worked before and no more.

Can you make a minimal reproducible case and submit it as bug report?

#3

There’s nothing specific to Show, but we did extensive work on the Tab engine to get rid of some edge cases. Sounds like maybe we created a new one?

A bug report with a sample would be helpful.

#4

seems to have to do with my websdkuicontrols. if there are any on the webpage, it hangs into the debugger and you are nowhere. tried to do an autotab but it is the same.
if I remove all the websdkuicontrols, the webpage is shown correctly.
I tried with the last beta and it is still there.

#5

So, may be :

I’m afraid that in some circumstances people mess with the DOM and events in a such way they can confuse the Xojo engine and their tracking of states and logic when Xojo changes something. Maybe you touched some of those places…

#6

did something change in the way we need to handle websdkuicontrols between 2020r21 and 2021r1 ?

#7

Create a minimal test app showing the problem, submit it to Feedback, and let Greg inspect it.

#8

send a private feedback with sample project for @Greg_O_Lone to tell me what"s wrong ? thanks.

#9

Hi @Greg_O_Lone , any news on this one please ? thanks. I’m really waiting for it to go on my websdk’s.
feedback://showreport?report_id=64840

#10

Another big change I can think of is that we changed the engine behind the scenes of JSONItem and it’s much more particular about encodings than it was before.

In your routine where you are splitting apparent the initial value, you are using &h09 for a tab character. One problem I see is that this character has an ASCII encoding and just concatenating this with a UTF8 string means that you end up with a mixed encoding string. JSON requires UTF8.

FYI, it would have saved me a lot of time if you had mentioned that it also does not fail if the initial value isn’t set at all. That narrows down the scope of where the problem could be by at least 90%.

#11

Yeah it’s the structure. Structure elements, even if they are strings, don’t have encoding information associated with them.

I suggest you make an extension method for ensuring the encoding of a string that looks something like this:

Public Function ToUTF8(extends s as string) As String
  If s.Encoding = Nil Then
    Return s.DefineEncoding(Encodings.UTF8)
  End If
  
  If s.Encoding = encodings.UTF8 Then
    Return s
  End If
  
  Return s.ConvertEncoding(encodings.UTF8)
End Function

and then add that in each place where you are pulling data from that structure… like this:

badge.Add lv.badge.ToUTF8
badgeIndicator.Add lv.badgeIndicator.ToUTF8
caption.Add lv.caption.ToUTF8
fontawesomeiconname.Add lv.fontawesome.ToUTF8

Making those four changes makes your control work again (and will work in older versions as well)

1 Like
After the crash with no evidence of debugger/webapp.exe errors, system restart required (event error on ucrtbase.dll)
#12

will try to narrow that.
but in the example project I provided in the feedback, there are simple “line1” “line2” … values in the initialvalue property, there is no tab. and it still doesn’t show anything and hang in the debugger.

#13

This is another one of those places where using unencoded strings can lead to unpredictable results.

#14

many thanks for your time Greg.

#15

anyway would be nice in future versions to have some message instead of hanging nowhere lost in the debugger !

1 Like
#16

I’ll look into that. It’s a strange thing because it’s not really in a place where we can throw an UnhandledException in the session, but we can probably throw it at the application level.

Unfortunately it’s in internal code that the debugger can’t show to you, so at the moment the debugger is doing the best that it can.