379916 - Scrollbar thumb drawing is broken with javascript disabled since XUL scrollbars landed

Status: RESOLVED FIXED

(Core :: XBL, defect, P4)

Description

[monkeypox37]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a5pre) Gecko/20070506 Minefield/3.0a5pre
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a5pre) Gecko/20070506 Minefield/3.0a5pre

If javascript is disabled in the browser and the user has the System appearance preference set to have the scrollbar arrows "together" at one end of the scrollbar then the drawing for the scrollbar thumb doesn't redraw correctly when the user scrolls the page.

Reproducible: Always

Steps to Reproduce:
1. disable javascript
2. scroll a page
3. notice thumb doesn't draw correctly, as shown in linked image



This works correctly either with javascript enabled or arrows at both ends.

Comment 1

[philippe (part-time)]

Confirming, happens on 10.4.9ppc and 10.3.9.

Comment 2

[Colin Barrett [:cbarrett]]

Looks like this is caused by the JS that gets run at XBL initialization for scrollbars not getting run. That code shows/hides scrollbar arrows based upon system settings (two on the bottom, one at each end, etc).

Comment 3

[Colin Barrett [:cbarrett]]

Bug 276205 caused a regression which made XBL constructors not run, according to bz.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So as far as I can tell, the fix for bug 276205 changed things so if JS is off constructors will not run.  Then later, bug 292591 beefed up AllowScripts() a good bit, thus probably making the earlier fix unnecessary (because AllowScripts() will fail for content-provided constructors).  I thought I'd tested this when fixing bug 292591, but apparently I tested 1.7 branch back then...  So this might be affecting marquee and whatnot on the 1.8 branch.

In any case, I think we should probably just back out the fix for bug 276205.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Note that no matter what we do in bug 384612 comment 4 applies -- scrollbars may get better, but chrome XBL in general will still have issues...

Comment 6

[Boris Zbarsky [:bzbarsky]]

In particular, we probably need to fix this on branch.  I don't know when I'll have time to test things there and test the backout, unfortunately.  :(  If there are some convenient testcases (i.e. regression tests for the various bugs), that would be a big help.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm more fine with disabling js also breaking remote xul and marquee. Backing out bug 276205 seems worse. Maybe we can allow it just for chrome bindings? Seems like we've talked about that before?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Right, I'm saying only allow it for chrome bindings.  That's what the current AllowScripts() checks would do if JS is disabled.  That would allow marquee to work while not allowing ctors of non-chrome bindings to run.

Comment 9

[Daniel Veditz [:dveditz]]

Why do we need this in a 1.8.1.x release? Looks like it's been broken since bug 276205 (then entire lifetime of FF1.5)

Comment 10

[Boris Zbarsky [:bzbarsky]]

It's a web-compat issue on the branch just like on trunk.  I think it should be fixed for the same reasons that it should be fixed on trunk: so that things that are not a priori script don't break for users who disable script.

Note that scrollbars are not the only thing affected.

Comment 11

[Daniel Veditz [:dveditz]]

We've already got a big pile of stuff for 1.8.1.5 and this has been hanging around for a while. Get it fixed on trunk and we'll take a look at the patch(es), but not actually blocking.

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Patch in bug 384612 should have fixed this.