B4J Question Runs Great on FireFox not so much on Chrome

Dogbonesix

Active Member
Licensed User
Longtime User
I created a B4J web app https://Grok3.com that runs great on FireFox.

On Chrome it launches fine. To continue I leave the Login and PWD blank, to view sample data, and click the continue button - the next page rarely completely populates - but when it does the populated data is immediately cleared. More often that not it says "Server is currently not available."

I suspect it has something to do with ws.connect or wss.connect or some-other timing issue. But I really don't know. If anybody has a clue - I would appreciate any insight.
 

drgottjr

Expert
Licensed User
Longtime User
your .js script has an interesting timeout feature which
corresponds to chrome's difficulty. chrome also
reports a problem with your script's closing the
socket before a connection has been made.

the "whiping out" you notice, is this repetition every
1 second of chrome's attempt to connect. a status
of 101 is websocket talk for the upgrade from http(s)
to ws(s). it's failing. whether it's related to the way
your client is configured to timeout every 1 second
seems likely. why firefox doesn't croak remains to
be seen. i can tell you that i did see similar messages
in firefox, but it was able to recover quickly.

without getting into the timeout and repeated status
101 reports (they will go on as long as you leave chrome
running on the page), i think you need to establish
whether chrome can connect with your server and
remain connected. the easiest way to do this is with
a simple "hello, websockets" script. there are numerous
examples available. run it. is there a connection? does
it disconnect immediately? after the client and server
exchange greetings, what happens? (if the server is
configured correctly, nothing special should happen.)
report back.

i have a websockets server that streams video to/from
clients running on chrome. this does not make me an
expert, but i can tell you that chrome's support for
websockets made that part of the project almost trivial.
its handling of connecting, sending, receiving, disconnecting
and error reporting were exemplary. chrome is not without
its (annoying) quirks, but there are 2 other possible
guilty parties in your case. it would be good to narrow
things before indictments are handed up.
 
Upvote 0

drgottjr

Expert
Licensed User
Longtime User
following up my own post:
i can connect to your websockets server
using chrome. the connection is cleanly closed
shortly thereafter because i can't supply whatever
payload the server is expecting. this is not
unexpected; servers should be configured not
to allow themselves to become victims of
timewasting probes, malicious or otherwise.

however, there was no trace of the troubles
that accompany connecting with the server through
the grok page.

a little research revealed that chrome has/had
issues with the reconnecting-websocket module
that you use. it seemed to involve timing. i've
attached a screen cap from SO. from what i
could see in monitoring chrome's pathetic
attempts to connect, timing was involved.

i don't use the reconnecting-websocket module.
it was written 10 years ago and hasn't been
updated for at least 5 years. websockets
development may have evolved since then. and
there are certainly less agressive ways of keeping
tabs on connections. anyway, if you want to start
researching "reconnecting-websocket and chrome"
and "reconnecting-websocket and firefox", you
may find a reference to the problem you're
experiencing.
 

Attachments

  • grok3.png
    grok3.png
    9.4 KB · Views: 188
Upvote 0

Dogbonesix

Active Member
Licensed User
Longtime User
Alcon. Thanks for the insights, especially the timing issue. Drgotjr how do I figure out who is the guilty party? Also, I am not clear where wss.connect is to be located. currently it is only in the Main module (one instance) but maybe it should be in all the modules? .js script timing - Can it be changed?
 
Upvote 0

drgottjr

Expert
Licensed User
Longtime User
you're going to need someone who is familiar with the reconnecting-websocket module, what looks like a main driver on your page
(https://grok3.com/reconnecting-websocket.js). the image i posted was to show that timing issues with this module and chrome were occurring at least as far back as 2016 (which, coincidentally, was the last update to the module). in the case in question, the poster said he found relief by adjusting a particular setting in the module. if you wanted to try that, you'll have to hunt through the module for that particular setting. the author of the module may still be around and willing to answer a question (no need to tell him i sent you). messing with a big work like that, especially one that meshes with other modules, can cause even bigger problems.

wss://grok3.com/butler2 answered the call when i connected with chrome. but you have to connect through a javascript script speaking websockets. if you just pump that address in on chrome, you won't get far.

i don't see how you fix this by yourself, but i think the controlling code is in the reconnecting-websocket.js module. it probably should have been updated as websockets evolved. maybe it was in some other format; the guy could have found a paying job. but it does have settings which can be modified. the way it chose to go about keeping clients in line threw me. it just struck me as reflecting the thinking of its era. not that there's necessarily anything wrong with that. you should expect to spend some time looking for issues between reconnecting-websocket and chrome . i saw a number of hits. you're less likely to find issues with reconnecting-websocket and firefox, since firefox isn't chrome.

reconnecting-websockets.js is what you're using to interface browsers with your program logic. in theory, using a different interface for users on chrome, shouldn't affect the way the program works. it's like when you port your phone number to a different provider. or change isp's. this has been a problem for web developers since day one, right? what worked on netscape didn't work on internet explorer and vice versa. programmers had to kludge. i'm not saying reconnecting-websocket does not work with chrome, but you need to talk (pay) to someone who knows the module and who - most likely - wll have seen this issue before.
 
Upvote 0

alwaysbusy

Expert
Licensed User
Longtime User
I believe I had a similar problem with it and used this one instead: https://github.com/appuri/robust-websocket

You should make this change in b4j_ws.js:
B4X:
...
   if (typeof ReconnectingWebSocket === 'undefined')
        b4j_ws = new WebSocket(fullpath);
    else
        b4j_ws = new ReconnectingWebSocket(fullpath);
        b4j_ws.onmessage = function (event) {
   ...

to:
B4X:
...
   if (typeof RobustWebSocket === 'undefined')
        b4j_ws = new WebSocket(fullpath);
    else
        b4j_ws = new RobustWebSocket(fullpath);
        b4j_ws.onmessage = function (event) {
   ...

Alwaysbusy
 
Upvote 0

Dogbonesix

Active Member
Licensed User
Longtime User
Alcon, thanks for the insights. I will certainly donate if I get a solution. I do have a couple other techs that might be understand what was all said. In the meantime I am posting in the app that using FireFox is the best idea.
 
Upvote 0

Dogbonesix

Active Member
Licensed User
Longtime User
Attached is the Main module for the app. Copy of main module except the passwords are changed. It is the first time I have tried to include SSL so that could be a problem. And I am not sure where "srvr.AddWebSocket("/wss", "Start")" is correct.
 

Attachments

  • Main Module SSL_sample.txt
    3.2 KB · Views: 200
Upvote 0

drgottjr

Expert
Licensed User
Longtime User
i'm seeing stuff that troubles me. but you seem to be hopeful of
a quick fix, so i'm reluctant to mention things that jump out
at me during the most superficial of scans, eg:

in your b4j module (your last attachment), you have:

B4X:
    srvr.Port = 80
    ConfigureSSL(443)
    srvr.Start

i'm not using this code myself, but something doesn't look right. port 80 does not handle ssl. why are you setting port 80
but configuring ssl (on port 443, naturally). who's listening on port 443 if the server is on port 80?

in your main page (grok3.com, you have:

B4X:
// Connect to the B4J Server = the handler helloworld.bas is called
   b4j_connect("/ws");

in b4j_ws.js for that b4j_connect method, there is this:

B4X:
    fullpath = ((l.protocol === "https:") ? "wss://" : "ws://") + l.hostname + ":" + l.port + absolutePath;

the "absolutePath" variable is the "/ws" you passed in b4j_connect(). if you're running secure, i don't think you can go
backwards to "/ws", which is what "/ws" would tend to imply. shouldn't it be "/wss", assuming you have such a directory?
i could envision chrome freaking out if you were trying to load unsecured resources from https. it goes berserk for much
smaller transgressions.

by jumping directly to your second page (post #14), you skip over that particular connect command and issue a totally different one (b4j_connect("/butler2");) butler2, as i think i mentioned earlier, is where your wss server is...
 
Upvote 0

alwaysbusy

Expert
Licensed User
Longtime User
I think you should add your WebSocket pages with the /ws prefix:
B4X:
srvr.AddWebSocket("/ws/butler2","butler2")
' it may also be (not sure if this was only needed for ABM/BANano)
srvr.AddWebSocket("/ws/www/butler2","butler2")

It may cause the loop: http request /butler2 -> upgraded to ws/butler2 -> does not find the /ws/butler2 handler -> disconnects -> goes back to http /butler2 -> upgraded to ws/butler2 -> ...

It would also be interesting what exactly you do in the Websocket_Connected method of your Butler2 page.

Alwaysbusy
 
Last edited:
Upvote 0

Dogbonesix

Active Member
Licensed User
Longtime User
Wow, thanks all. I am the designer and have limited web socket experience but my partner is skillful at such. He will understand the above but it will take a few days to talk to him. In the mean time - I find it curious that the app loads fine (the Main and Start pages) fails on the next page (Butler2.bas) and subsequent pages work quite well. The problem occurs on the Butler2.bas page - it seems. I have attached Butler2.bas for further review.
 

Attachments

  • butler2.bas
    44.8 KB · Views: 190
Upvote 0

Dogbonesix

Active Member
Licensed User
Longtime User
Found the error - just don't know how to fix it.
Chrome cancels network request if request is initiated from a websocket JS call of window.location.replace("indexNewLocation.html")
In the Sub below:
Private Sub WebSocket_Connected (WebSocket1 As WebSocket)

Log("Connected")
ws = WebSocket1

' ====================
Dim session As HttpSession = ws.UpgradeRequest.GetSession
If session.HasAttribute("state") = False Then
state.Initialize
state.Number = Rnd(1, 101)
session.SetAttribute("state", state) 'sets a reference to the state object.
Log($"Creating new state. Number = ${state.Number}"$)
Else
state = session.GetAttribute("state")
Log($"Reusing previous state. Number = ${state.Number}"$)
End If
' ====================
Dim demoListObjects As List
demoListObjects.Initialize

Dim g1 As Int
g1 = 0

Dim ShowPWD As String = GetPWD
Dim ShowUser As String = GetUser
'headertext.SetHtml("Grok Ver Adv 1.21 written by Bill Cook and Christopher Gumpper.<br /> Grok is data management and organizational tool composed of five catagories (the colored buttons below). These buttons represent a global picture of your Village/Campus. Leave the Login and PWD blank to tour Gilligan's Island.")

If ShowPWD = "" Then
ShowPWD = 10
End If

If ShowUser = "" Then
ShowUser = "Sample"
ws.Alert("Redirecting to Sample Login")
End If

HideAll
ShowBldgs
SelLoc = "Nav"

listbox1.sethtml("") ' Campus, Building

PostData("SELECT accountID,userName,password,HomeDesk,HomePWD,HomeID FROM Acme_Accounts Where userName = " & "'" & ShowUser & "'" & " AND Rank = " & "'" & g1 & "'" & " ",Valid_Acct)
End Sub

Does anybody have a clue to correct this error?
 
Upvote 0
Top