Closed tomayac closed 4 years ago
Would it be possible to fix the bug in the existing APIs, instead of introducing new APIs and hoping we implement them bug free this time?
Or is there something about moveTo/resizeTo that makes them impossible to implement without this extra frame?
PWAs could maybe just call moveTo() and resizeTo() in window.onunload
to avoid flicker at launch... flicker on close may be more palatable. This relies on OS WMs persisting window bounds for the next launch, IIUC?
[I]s there something about moveTo/resizeTo that makes them impossible to implement without this extra frame?
Since these calls would have to happen before even a window is shown, I don’t think there’s a way to make this happen, but I’m not a browser engineer, so maybe there is?!
PWAs could maybe just call moveTo() and resizeTo() in window.onunload to avoid flicker at launch
This would solve the following standalone launches, but not the very first standalone launch, would it? Especially when we think potential future PWA distribution through tools like Web Packaging that never had an in-tab pre-installed life.
I vaguely remember someone suggesting we add a 'preferred_window_size' to the manifest at one point. @mgiuca, was that real, or am I imagining things?
Also, is there a reason we'd want to override the size and position from when the window was last opened? Is this a "I had it open in the browser, now it's in a window" kind of thing?
I don't think this is something we want to solve with launch events, but I have to admit, there would be a nice symmetry with window.open
...
https://github.com/w3c/manifest/issues/436
I agree, doing this in the launch event is a bit of a mismatch. If you just want to set your window size, having to intercept all launches just to do so would be overkill. Also the launch
event may not fire on every situation where a window will be opened.
I brought up the launch
event because in https://github.com/w3c/manifest/issues/436#issuecomment-203459960 it was suggested as a potentially good fit. I'm happy to close the present issue and continue the discussion over on https://github.com/w3c/manifest/issues/436.
Some widget-like PWAs, for example, this tip calculator typically have fixed size requirements. While they might work responsively, it makes more sense to be able to restrict the window to the known size they were optimized for in order to avoid subpar experiences:
The functions
window.resizeTo()
andwindow.moveTo()
both cause a frame of "unmoved and unresized window". For a demo: install https://speckle-galleon.glitch.me/ (just via the three dot menu, it's not a PWA) and resize and move the window to any size and position, close the app, then relaunch it. You will see the window at the position and size when you closed it, and only a moment later it'll be moved and resized to the desired size.It would be great to be able to optionally determine a window position and size in the
launch
event.