hotwired / hotwire-rails-demo-chat

Repository from the Hotwire demo
235 stars 43 forks source link

Demo issues, older browsers, feature/content_security policies #11

Open dvodvo opened 3 years ago

dvodvo commented 3 years ago

Replicating the process of generating the chat demo, there are a number of points I have picked up; if deemed necessary, I am willing to break these up into individual ones.

1 - un-reproducible behaviour. The elimination of the previously submitted string in the new message form remains in the refreshed form. form:

<%= turbo_frame_tag "new_message", target: "_top" do %>
  <%= form_with(model: [ @message.room, @message ],
        data: { controller: "reset_form", action: "turbo:submit-end->reset_form#reset" }) do |form| %>

stimulus controller

import { Controller } from "stimulus"

export default class extends Controller {
  reset() {
    this.element.reset()
  }
}

It even stays put as other messages are being driven to the room Screen Shot 2021-02-06 at 10 39 35

Something might be wrong with the stimulus set-up, something missing, but where/how to de-bug?

2 - Feature policies. Rails's guide defines a default state.

config.action_dispatch.default_headers = {
  'X-Frame-Options' => 'SAMEORIGIN',
  'X-XSS-Protection' => '1; mode=block',
  'X-Content-Type-Options' => 'nosniff',
  'X-Download-Options' => 'noopen',
  'X-Permitted-Cross-Domain-Policies' => 'none',
  'Referrer-Policy' => 'strict-origin-when-cross-origin'
}

This default state for referrer is actually unaccepted by Chromium. origin-when-cross-origin is what google digests. The google default to a very restrictive position. Feature policies and Content-Security policies come to mind, given that hotwire is dealing with frames. Is this not a potential for breakage? what guidelines should be followed?

3 - Some older browsers (I recognize and accept my quirkiness), take a pass on hotwire - Safari 9, but also Safari 11 which isn't exactly cro-magnon...
Screen Shot 2021-02-06 at 10 39 55 Do we have an idea of which standards are baseline in order to inform/handle such uses?

4 - premisse: Firefox is my go-to browser and gets used heavily. In my observation, javascripts generate unexpected behaviours relating to the DOM. Screen Shot 2021-02-06 at 12 36 31 This is an example. Aside form a page refresh, is there a way to 'reboot' the DOM if one notices the browser acting flaky (again this may be a moot point given the premisse) ?

thestelz commented 3 years ago

1 - un-reproducible behaviour.

I'm having the same issues. I did noticed that they have since updated the new form (source), but I still can't get it to work as expected (neither can any of my co-workers).