Open Bug 443076 Opened 12 years ago Updated 1 year ago

Hidden <browser> xul elements don't get reflowed on style property change

Categories

(Core :: Web Painting, defect)

defect
Not set

Tracking

()

People

(Reporter: bholley, Unassigned)

References

Details

(Keywords: mobile)

In the fennec chrome we have an invisible <browser> element that we blit to a canvas in order to handle zooming and panning. If the document sets a <meta> viewport tag, we need to be able to resize the browser once the document has loaded and have a reflow occur. Currently, when we set browser.style.width or browser.style.height, the changes don't take effect until the next page is loaded, essentially meaning that the viewport used to render a page is the viewport of the page loaded before it.

dbaron seemed to know exactly what the problem was. He suggested hacking nsViewManager::SetWindowDimensions in view/src/nsViewManager.cpp and replacing if (IsViewVisible(mRootView)) with if (true) to see if that was the issue. It does indeed fix it, so presumably some sort of change above that hack needs to happen. dbaron had something in mind.
See bug 227361 for the history of the code in question.

We probably want a way of indicating that a docshell is not visible for tabbrowser to use.
Blocks: 436083
dbaron, any chance you can take a stab at this?  would really help out mobile.
Flags: blocking1.9.1?
Keywords: mobile
See also bug 453896 (which might even have fixed this).
Flags: blocking1.9.1? → wanted1.9.1+
So in what exact way is the <browser> invisible in this case?
visibility:hidden
That's odd.  that shouldn't cause IsViewVisible() to return false on its own, I wouldn't think.  Why does that happen?
Oh, so we actually hide the view.  Which means we have the same problem with hidden-visibility iframes even with JS querying stuff (or did until dbaron's changes from bug 453896).

I don't think bug 453896 should have fixed this, though, since nothing is triggering a flush on the child frame in the case described in comment 0.

Sounds like we either need to sprout something on docshell to ignore the view visibility in some cases or sprout something on docshell that we could use instead of visibility to optimize away tab resize reflows.

I guess here's a question: do we care about optimizing away resize reflows of hidden-visibility iframes in general?
I'm not aware of a need to do that.
In that case, we should probably move away from view visibility and instead just check with the presshell directly.  This can in turn check with the docshell, and we can toss a property on there for tabbrowser to set.  Embeddors can continue doing the right thing there via their treeowner, presumably.
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.