59 bytes, text/x-review-board-request
See bug 1368208 comment 56: > I think I'll land this with 508816-1.xul disabled. The scroll buttons seem > to suffer from some weird invalidation bug that I can reproduce even in > nightly (e.g. in the all tabs list or in the bookmarks menu). My patch > doesn't seem to make this worse but changes the timing such the reftest now > exposes this bug. I added some logging to _updateScrollButtonsDisabledState to see if it enables/disables the buttons as expected. It does do so, i.e. the buttons' disabled attributes get updated, but it seems that somehow this doesn't necessarily get rendered.
With the timing aligned, the test doesn't fail anymore in a tryserver run of 20 rebuilds on all platforms: https://treeherder.mozilla.org/testview.html?repo=try&revision=1fe08c6d023035d382df88a2b4e08317c85ab53f This can unblock bug 1457719, even though the reftest is still running unprivileged until bug 1465457 is fixed.
I'm still seeing what I wrote in comment 0, so I think we have a legitimate bug here, not just a test issue. If we can enable the test regardless, that's fine with me, but we'll still want to track the underlying issue I filed this bug for.
(In reply to Dão Gottwald [::dao] from comment #3) > I'm still seeing what I wrote in comment 0, so I think we have a legitimate > bug here, not just a test issue. If we can enable the test regardless, > that's fine with me, but we'll still want to track the underlying issue I > filed this bug for. Sounds good, I cloned this to bug 1465730.
Summary: arrowscrollbox scroll buttons are intermittently rendered as disabled or enabled when they should have the opposite state → Align the timing of "508816-1.xul" and "508816-1-ref.xul"
You need to log in before you can comment on or make changes to this bug.