Confirming, happens on 10.4.9ppc and 10.3.9.
Status: UNCONFIRMED → NEW
Component: General → Widget: Cocoa
Ever confirmed: true
Product: Firefox → Core
Version: unspecified → Trunk
Assignee: nobody → joshmoz
QA Contact: general → cocoa
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.
12 years ago
Assignee: general → jonas
Flags: blocking1.9? → blocking1.9+
Depends on: 384612
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.
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 220.127.116.11 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.
Priority: -- → P4
Patch in bug 384612 should have fixed this.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.