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




12 years ago
11 years ago


(Reporter: monkeypox37, Assigned: sicking)


Mac OS X
Dependency tree / graph
Bug Flags:
blocking1.9 +
blocking1.8.1.5 -
wanted1.8.1.x +
blocking1.8.0.13 -
wanted1.8.0.x +

Firefox Tracking Flags

(Not tracked)





12 years ago
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.
Confirming, happens on 10.4.9ppc and 10.3.9.
Blocks: 370439
Component: General → Widget: Cocoa
Ever confirmed: true
Product: Firefox → Core
Version: unspecified → Trunk
Assignee: nobody → joshmoz
QA Contact: general → cocoa
Assignee: joshmoz → 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).
Bug 276205 caused a regression which made XBL constructors not run, according to bz.
Assignee: cbarrett → general
Component: Widget: Cocoa → XBL
Depends on: 276205
QA Contact: cocoa → ian
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.
Flags: blocking1.9?
Assignee: general → jonas
Flags: blocking1.9? → blocking1.9+
Target Milestone: --- → mozilla1.9alpha6
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...
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.
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
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?
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.
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)
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.
Target Milestone: mozilla1.9alpha6 → mozilla1.9beta1
We've already got a big pile of stuff for 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.
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5-
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13-
Duplicate of this bug: 391265
Target Milestone: mozilla1.9 M8 → ---
Priority: -- → P4
Patch in bug 384612 should have fixed this.
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.