J

jrose

Had Activity Monitor open at the point of crash this time: 826.6 MB real memory, 121.17 GB virtual memory. Which is normal for Discord + the "JavaScript memory cage", the new process looks similar and so did the equivalent Safari process, IIRC. There is a CPU spike in the Activity Monitor history but I think it's just as likely to be the crash log collection as an actual spike in the WebKit process.

The worst part is I was just idling this time. Previously it'd been happening while I was taking an action in Discord, though the action varied: sending a reaction, playing an embedded video, … But this time, given the reload state, I think it was just sitting there as the frontmost tab, receiving the usual updates in the background.

Also not seeing it on Safari after a few hours of active and passive usage, whereas with Orion it usually shows up within 5 minutes of actively using Discord.

In case it helps:

Still busted, or re-busted.

Happening on Discord fairly frequently for me, here's one of the crash reports (they all look the same).

The regular buttons in the Orion toolbar have tooltips, but the ones that are part of the location bar do not. I had to click the new Profile button to find out what it does.

Orion, OS version; hardware type:
Version 0.99.121-beta (WebKit 614.1.20)
MacBook Pro (macOS Monterey 12.6 build 21G115)

Image/Video:

Compatibility mode does not help. I'm afraid the video isn't very elucidating either, because it's hard to discern the extra milliseconds of delay that makes it feel like lag.

This bug isn't about the crash. Does Orion have a test for the tab process crashing?

Still happens in 118.1. Not sure why I didn't think to attach the crash log, here you go. Looks like a WebKit bug again.

Afraid so, though it seems a little better in some channels and not others. New sample:

Steps to reproduce:

1. Go to a page that crashes the tab process. (Mobile Wikipedia seems to do the trick at the moment: https://en.m.wikipedia.org/)
2. Try Cmd-Shift-{ to change tabs, or Cmd-W to close the current tab. Nothing happens.
3. Use the mouse to change tabs, or Cmd-T or Cmd-N to make a new tab/window.
4. Go back to the broken tab and try again. Now things work.

Orion, OS version; hardware type:
Version 0.99.117-beta (WebKit 614.1.20)
MacBook Pro (macOS Catalina 10.15.7 build 19H2026)

Reproduces after quitting and reopening, including in a new tab in an existing restored window.

Steps to reproduce:

1. Set "New windows open with" to "Start Page"
2. Cmd-N. I get a grey background.

Orion, OS version; hardware type:
Orion 0.99.111-beta
macOS Catalina 10.15.7
JavaScript and cookies disabled by default

Notes
This happened once in a new tab in an existing window, but I can't reproduce that now; I poked at it by opening the sidebar and that brought the Start Page contents up. This also works in new windows, but the next window will still have a grey background. About to test quitting and re-opening…

Er, yeah, to be clear that’s what I’m hoping for. I thought I manually tested it and it didn’t work (because eBay is usually www.ebay.com, not just ebay.com), but maybe I got it wrong.

I've been taking the leap of browsing with JavaScript off and cookies off by default, but that gets tricky for sites like eBay that hop you through several different subdomains to sign in. Ideally I'd be able to turn on JavaScript and cookies for "all of ebay.com", though if I had to do it in Preferences that wouldn't be too surprising. (Spelling it "*.ebay.com" would make it unclear whether it applied to "foo.bar.ebay.com", but maybe that's fine, because no one would ever want it not to.)

Looks like the preference has a typo: "⌘-z" instead of "⌘-Z" (or, honestly, "⌘Z", which is more conventional).

I think that's standard behavior for panels, but that's definitely a problem I've had too.

Aha, https://discord.com/ (not the web app) does reproduce it reliably, probably because the web app updates the favicon in its JavaScript (like the issue @gp linked).