Closed Offroaders123 closed 1 year ago
(Just a quick side note unrelated to the actual issue: we have added UI considerations to the WCO article.)
(Just a quick side note unrelated to the actual issue: we have added UI considerations to the WCO article.)
Awesome, that would be an amazing feature! The UX on macOS is confusing at the moment, so an addition similar to that would be very much appreciated.
Also, I was wondering curious if having an option to use a more compact header on macOS is feasible? I feel like the height of the title bar for PWAs is fairly tall compared to other apps, like VS Code, or another app that uses the native toolbar height.
I believe the VS Code titlebar is about 26 pixels tall if I remember correctly, while the PWA height is more than that.
Maybe it would only make sense to apply it for the collapsed WCO layout, rather than the default "display": "standalone"
experience.
Awesome, that would be an amazing feature! The UX on macOS is confusing at the moment, so an addition similar to that would be very much appreciated.
(If you can, please consider starring the bug and commenting about your use case.)
Thanks for catching these issues! I filed two CR bugs to track the issues mentioned here:
Realized this has been open for a while, and the actual issues have already been fixed! Oops. Thanks for helping me out with these!
For my own PWA, I have a few implementations to allow for the creation of secondary app windows, and I have been using this system for a while now. Once I added support for Window Controls Overlay, I ran into some issues on Chrome OS when opening those secondary windows. These may be issues with the Chrome OS side of implementation, but I thought I would also add the issues to this thread first.
Popup Window Styling
My workaround to add a keyboard shortcut to create a second PWA window, like you would with
Ctrl+N
for a standard Chrome window, is to open a new "popup" window using a function which opens the same page in a new window, also in standalone mode like the original PWA app window.This is what the result popup looks like on Windows, it is the same for both the base PWA window, and the new window created from the
window.open()
call.This is what the base PWA window looks like on Chrome OS.
This is what the result popup window looks like on Chrome OS. For some reason the PWA Information and Window Controls Toggle buttons aren't present.
Blob URL Crashing
Another issue I have run into is that opening a popup window using a Blob URL from a WCO-enabled standalone PWA, using the
window.open(window.location.href,"_blank","popup")
method listed above, will cause Chrome OS as a whole to crash. I'm wondering if this possibly has to do with the issue above, as maybe Chrome OS doesn't know how the title bar should behave for a Blob URL in WCO-enabled standalone PWA mode.On Windows, this action is handled without issue, and the window title bar uses the navigating away from the origin layout, which I think makes a lot of sense for Blob URLs. The Blob URL is still part of my PWA's scope because it is under
https://stedit.app
, allowing it to open in standalone mode, but the user can still visibly see that you have navigated to a Blob URL, which is great.Another note for the Chrome OS issue, this crash will still occur if you have WCO disabled through the toggle button. This however will not occur for default standalone PWA window types that don't support WCO in the manifest. Those behave as expected.
Here is an example of that, I added my own
createDisplay()
function to Photopea using the DevTools console. It simply creates a new popup window from a Blob URL.Photopea doesn't support WCO, so the problem does not occur there. I think this layout type should also be the end goal for how standalone Blob URL windows should open on Chrome OS when WCO is enabled for the PWA.