Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dvodvo opened this issue Feb 9, 2021 · 1 comment · May be fixed by #26
Open

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

dvodvo opened this issue Feb 9, 2021 · 1 comment · May be fixed by #26

Comments

@dvodvo
Copy link

dvodvo commented Feb 9, 2021

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
Copy link

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).

abaldwin88 added a commit to abaldwin88/hotwire-rails-demo-chat that referenced this issue Jun 4, 2022
Upgrade to Rails 7 with `rails new` default project scaffolding

Fixes hotwired#11 Content Policy prevented stimulus controller from loading which caused chat input to not clear on submit
abaldwin88 added a commit to abaldwin88/hotwire-rails-demo-chat that referenced this issue Jun 4, 2022
Upgrade to Rails 7 with `rails new` default project scaffolding

Fixes hotwired#11 Content Policy prevented stimulus controller from loading which caused message input to not clear on submit
@abaldwin88 abaldwin88 linked a pull request Jun 4, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants