I've attached a minimal test page, which applies a vertical linear
gradient to the body.  The body contains several thousand paragraphs,
and as a result takes up more than 64k pixels of height.  If I attempt
to scroll this page to the bottom, either by pressing end or by holding
down page-down, the scrolling stops somewhere in the middle, right
around the 64k pixel mark.  Once scrolling stops, the page no longer
responds to any attempt to scroll with either the keyboard or the
scrollbar.  Force-refreshing the page returns to the top.

This depends specifically on rendered height: if I increase or decrease
the font size, the point at which scrolling freezes will move up or down
in the text accordingly.  If I decrease the font size enough, I can
reach the bottom of the page without triggering the problem.  The freeze
doesn't always occur at exactly the same location, but generally within
a few dozen lines of the 64k pixel mark.

I can reproduce this scroll freeze 100% reliably with this test case.

The test case seems oddly fragile in a few ways.  If I drastically
increase the font size on the html element (for instance, going to
50px), the problem goes away, but the gradient still mis-renders in many
places in the page (restarting, or showing a solid color).  If I replace
the relative 1.1em font-size on body with an absolute one, even one
resulting in about the same size, I see the same behavior: no scrolling
issue, but a mis-rendered gradient.

Reported upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=916624
, but I've reported it here as well because it may specifically occur
with Debian's build that uses system graphics libraries.  Two testers
using upstream builds said they could not reproduce the scroll freeze,
though they could observe incorrect gradient rendering.

I can reproduce this in safe mode, so it doesn't depend on configuration
or extensions.

- Josh Triplett

Am So, 15. Sep 2013 um 19:35:39 -0700 schrieb Josh Triplett:
behaviour (Debian/sid). However, stock Firefox 24.0 is not affected. It
scrolls and shows the page without problem.

Here is a real world example: https://bugzilla.mozilla.org/show_bug.cgi?id=582596
Iceweasel itself does not hang, it seems only the page drawing area is
affected. One can switch between different tabs and interact with
Iceweasel. The CPU usage is down. The scroll bar itself isn't stalled
either and the slider can be moved to the bottom and back to the top -
in this case the site-content is not shown but switching tabs back and
forth will uncover the top of the page again. Search and find does work
as far as I can tell. Even if I can't see results, the slider itself is
moving when navigating to the next hit, all the way down to the bottom.

Regards
Dirk

Am Do, 19. Sep 2013 um 18:38:37 +0200 schrieb Dirk Griesbach:

... which is only partly correct. Stock Firefox 24 and 25 both show the
gradient and scroll temp.html but also show the solid colors and
mis-rendering Josh mentioned.

Now, Iceweasel 25 doesn't show any gradient or color at all. However, it
scrolls the whole page without a problem.

This all happens with a Intel GMA950 with SNA acceleration enabled. If I
disable SNA so the default UXA is used, Iceweasel 25 will draw a
gradient with about a tenth of the size the gradient in stock Firefox.
At least it scrolls the page correctly and does not produce additional
solid lines and other mis-rendering like stock Firefox does. Changing
acceleration methods does not seem to have an impact on stock Firefox in
this regard.

Dirk