(In reply to Hiroyuki Ikezoe (:hiro) from comment #31) > Yeah at first glance it looks like it matches Chrome's behavior but in fact it doesn't match Chrome's behavior as a web browser unfortunately. > > > Maybe we'd need a callback into APZ to request a special kind of reflow which would help in these specific scenarios? > > I don't think it solve this issue at all. With interactive-widget=resizes-visual or interactive-widget=overlays-content any reflow should be triggered by the browser. > > I'd suggest backing bug 1988730 out for now. Created bug 2007493 to just disable this by default for now but still have the feature around for more tests. I'm curious about the follow-up, seems like something that APZ needs to support?
Bug 1943053 Comment 32 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #31) > Yeah at first glance it looks like it matches Chrome's behavior but in fact it doesn't match Chrome's behavior as a web browser unfortunately. > > > Maybe we'd need a callback into APZ to request a special kind of reflow which would help in these specific scenarios? > > I don't think it solve this issue at all. With interactive-widget=resizes-visual or interactive-widget=overlays-content any reflow should be triggered by the browser. > > I'd suggest backing bug 1988730 out for now. Created bug 2007493 to just disable this by default for now but still have the feature around for more tests. I'm curious about the follow-up, seems like something that APZ needs to support - but IMO this would be triggered by integrators like Fenix - it is the one owning and deciding the behavior of the toolbars, banners etc wrapping the browser which then needs to adapt the shown web content to the toolbars configuration sent by integrators. This flow reminded me of bug 2006842 - it is possible that Fenix will show of hide different banners at the top/bottom the screen. These would be dynamic or not and we need APZ to support them changing at anytime. Maybe we can link more bugs and work to this incipient meta?
(In reply to Hiroyuki Ikezoe (:hiro) from comment #31) > Yeah at first glance it looks like it matches Chrome's behavior but in fact it doesn't match Chrome's behavior as a web browser unfortunately. > > > Maybe we'd need a callback into APZ to request a special kind of reflow which would help in these specific scenarios? > > I don't think it solve this issue at all. With interactive-widget=resizes-visual or interactive-widget=overlays-content any reflow should be triggered by the browser. > > I'd suggest backing bug 1988730 out for now. Created bug 2007493 to just disable this by default for now but still have the feature around for more tests. I'm curious about the follow-up, seems like something that APZ needs to support - but IMO this would be triggered by integrators like Fenix - it is the one owning and deciding the behavior of the toolbars, banners etc wrapping the browser which then needs to adapt the shown web content to the toolbars configuration sent by integrators. This flow reminded me of bug 2006842 - it is possible that Fenix will show or hide different toolbars & banners at the top/bottom the screen. These would be dynamic or not and we need APZ to support them & their behaviour changing at anytime. Maybe we can link more bugs and work to this incipient meta?