Assertion failure: -mDynamicToolbarMaxHeight <= aOffset && aOffset <= 0, at layout/base/nsPresContext.cpp:3043
Categories
(Fenix :: Toolbar, defect)
Tracking
(firefox129 disabled, firefox130 disabled, firefox131 disabled, firefox132 fixed)
People
(Reporter: hiro, Assigned: mavduevskiy)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
If you use a debug build of Gecko, with enabling dynamic toolbars you will see this assertion quite frequently during scrolling the contents.
Though the assertion is in Gecko, this assertion is caused by a call site of setVerticalClipping with invalid values. The call site is here in EngineViewClippingBehavior::onDependentViewChanged.
Adding bug 1879370 as a regressor which introduced the call site.
Comment 1•6 months ago
|
||
Set release status flags based on info from the regressing bug 1879370
:mavduevskiy, since you are the author of the regressor, bug 1879370, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Updated•6 months ago
|
Assignee | ||
Updated•6 months ago
|
Assignee | ||
Comment 2•6 months ago
|
||
It looks like a recent change we introduced during microsurvey work. It added extra space to the top of the toolbar, making it larger than the defined and expected height of the containers. We could calculate the height on the containers real-time, based on the view parameters, but it would be a bigger change to the code base, and the added space to the toolbar wasn't an intentional change. Once that bug is fixed and the toolbar height is back to normal, the assertion will stop failing.
Comment 3•6 months ago
|
||
Agree with Mike that part of the regression when using the navbar is bug 1907879 which added a new element in the toolbar layout - the height of which would be used for setVerticalClipping
but not in setDynamicToolbarMaxHeight
.
Saw this problem IRL in bug 1912988 which also showed there are actually 3 issues, not just one and added fixes for them so this bug should be reevaluated once those land.
Comment 4•6 months ago
|
||
With the patch for bug 1912988 being merged I thing now this should be fixed also.
Hiro, can you confirm?
Comment 5•6 months ago
|
||
Mike says his patch for bug 1913006 should fix this assertion failure.
Reporter | ||
Comment 6•5 months ago
|
||
Yeah, on the latest nightly (ebf0e33ba93e), the assertion doesn't happen while testing bug 1917733.
(In reply to Chris Peterson [:cpeterson] from comment #5)
Mike says his patch for bug 1913006 should fix this assertion failure.
The patch for bug 1913006 is a part of the changes for bug 1912988.
Updated•5 months ago
|
Description
•