Flashing element on phx-connected / phx-disconnected

[luizbafilho]

Environment

• Elixir version (elixir -v): 1.15.7
• Phoenix version (mix deps): 1.7.10
• Phoenix LiveView version (mix deps): 0.20.1
• Operating system: MacOS Monterey
• Browsers you attempted to reproduce this bug on (the more the merrier): Firefox, Chrome and Safari
• Does the problem persist after removing "assets/node_modules" and trying again? Yes/no: yes

Actual behavior

The exact same problem as #2276

The phx-disconnected binding is executed on every page load before the LiveSocket is connected. This causes the flash_group to appear, although that only happens in Firefox (120.0.1), Chrome and Safari work as expected.

That can be verified in a fresh new Phoenix that just got generated.

Screen.Recording.2023-12-07.at.11.54.13.mov

[thomasfortes]

It has to do with the way that firefox and chrome handle websockets closing the connection, page refresh doesn't trigger the close event on chrome, so it starts "clean" and then the webserver just starts a new connection, while in firefox you need to check the disconnection.

After a bit of research I found this answer on stack overflow.

If you want to check what happens in live_view just add this line of code after livesocket.connect() in your app.js

console.log(liveSocket.socket.conn.addEventListener("close", (evt) => console.log(evt)));

After reload in firefox you'll get something like

close { target: WebSocket, isTrusted: true, wasClean: true, code: 1000, reason: "", srcElement: WebSocket, currentTarget: WebSocket, eventPhase: 2, bubbles: false, cancelable: false, … }
app.js:11576:67

While in chrome you'll get an undefined.

Also, this isn't a live_view issue, probably a phoenix socket issue about how it handle disconnects and the wasClean property, I would start debugging putting a console log in this part of the code and if there's no result I would check all the others this.closeWasClean of the file.

---

Ok, did a bit of an exploration here and it seems that chrome and safari doesn't send the 1001 CLOSE GOING AWAY websocket code (which executes in the next page load, doesn't matter if it is a refresh or if you go to a completely different website), but if you wrap the this.triggerChanError() with an

    if (closeCode !== 1001) {
      this.triggerChanError()
    }

the error disappears.

It's pretty late right now and I did not test it extensively, but I think that this should be enough and will not create any issues, but I'm hoping to hear more opinions before submitting a PR.

[chrismccord]

As far as I understand it, this is only happens when the the user hard refreshes the page, right? In such cases, I don't consider this an issue. The browser is losing connection. You can override and try to debounce yourself in firefox, but it's going to be tricky. 1001 can be either the client going away or the server, so you want to be careful to actually show the error disconnected state if it was indeed the server going away long term.

liveSocket.getSocket().onClose(e => {
  if(e.code === 1001){ document.querySelectorAll("[phx-disconnected]").forEach(el => {
    // hide now and show later if we are still disconnected and here
  })
})

[damir]

It happens randomly when clicking on logo from register page. But it does not flash when switching between two live views, ie. clicking between two register links generated with phx.gen.auth

mix phx.gen.auth Store User users
mix phx.gen.auth Backoffice Admin admins

flashing - http://localhost:4000/users/register => http://localhost:4000
no flashing - http://localhost:4000/admins/register => http://localhost:4000/users/register

[philipp-kempgen]

fwiw: I thought the flickering of that alert box is somewhat distracting during development.
Happens on reloads in the browser and on server-side edits for me.
I'm wondering if it would be feasible to add a small delay using a CSS transition maybe ...

[philipgiuliani]

Our customer is also not happy about this flashing box when reloading the page or when coming back to if after the browser was long in the background (especially Firefox).

[SteffenDE]

This should be fixed with #3680.