code.pyret.org
code.pyret.org copied to clipboard
brownplt
embedded URLs seem to work in only some browsers
<body>
<iframe src="https://code.pyret.org/editor" width="800" height="400" title="Embedded Pyret Editor"></iframe>
</body>
On macOS Catalina 10.15.5, this works fine in Firefox and Safari, but not in Chrome or Brave (even under private browsing).
Are you loading the embedding page from a file:/// URL? I think there are different defaults across browsers for what that “origin” is allowed to do. I see a spinning Bonnie in Chrome/Brave for that case but it works if I load from a localhost URL serving the same file
On Fri, May 29, 2020 at 5:35 AM, Shriram Krishnamurthi < [email protected] > wrote:
On macOS Catalina 10.15.5, this works fine in Firefox and Safari, but not in Chrome or Brave (even under private browsing).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub ( https://github.com/brownplt/code.pyret.org/issues/330 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAA5IU5RTRUAR2INBDVZDGDRT6T2VANCNFSM4NOADPHA ).
Can you take a look at
https://cs.brown.edu/~sk/tmp/embed-pyret.html http://cs.brown.edu/~sk/tmp/embed-pyret.html
? I get a spinning Bonnie on Brave AND Chrome, but not on Safari (i.e., just like on the desktop, but this time being served from HTTP/HTTPS over the Web).
For future reference, the entire file is
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<title>Test</title>
</head>
<body>
<h1>Full CPO</h1>
<iframe src="https://code.pyret.org/editor" width="800" height="400" title="Embedded Pyret Editor"></iframe>
<h1>REPL only</h1>
<iframe src="https://code.pyret.org/editor#hideDefinitions" width="800" height="400" title="Embedded Pyret Editor"></iframe>
<hr>
<address></address>
<!-- hhmts start -->Last modified: Fri May 29 08:34:37 EDT 2020 <!-- hhmts end -->
</body> </html>
Both links work for me in Chrome on Linux, and Firefox on Linux. In Safari on an iPad, it took me 3 reloads to get the page to fully load (and I can't get any menus to understand why not) but once it loaded, it loaded just fine and the REPL worked properly. I don't have Brave available on any machine to check right now...
Can someone try Chrome on macOS? @schanzer can you pitch in? Go to
https://cs.brown.edu/~sk/tmp/embed-pyret.html
and see whether Bonnie stops spinning (i.e., you get a usable CPO).
I'm guessing Shriram has 3rd party cookies disabled; I can toggle that setting and get the issue he reports, and it's consistent with Googling the error message in the console.
The fix should be relatively simple, which is to just fill localStorage with an in-memory cache if it's not available. Some logging infrastructure won't work and logins might not work without extra work on top of that, but it will fix the immediate issue.
On Tue, Jun 02, 2020 at 1:29 PM, sorawee < [email protected] > wrote:
Chrome on macOS here: yes, it stops spinning, and the REPLs work fine.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub ( https://github.com/brownplt/code.pyret.org/issues/330#issuecomment-637788666 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAA5IUYUVQXZAWDI27DJA4LRUVOMJANCNFSM4NOADPHA ).
Ah, I have an unfortunate amount of experience fixing iframe things with these problems, so I can take a look at this.
Incidentally, is there interest in a lightweight embedded version that isn't just the full experience in an iframe? I assume someone might want to embed this into a textbook or some other context where they don't want things like the file features and some of the other UI to be visible.
There actually is some existing support for a "lighter-weight" UI that hides parts of the UI: #327. I view that particular implementation as a bit of a stopgap glued onto the current CPO implementation, but in principle we are fine with the idea.
@shriram is this still worth keeping open? Anchor is highly-embeddable, and we use it in our HoC. The fact that no one has commented on this for CPO in almost 3 years suggests it's not a pressing need, even if the issue still exists.
Well, it was a pressing need for the main user, namely me. But since we are moving over to Anchor, there's no point worrying about this. Closing.