Closed Bug 420363 Opened 16 years ago Closed 16 years ago

Scrollbars missing due to <meta http-equiv="MSThemeCompatible" content="no">

Categories

(Core :: Widget: Cocoa, defect, P3)

PowerPC
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.1b2

People

(Reporter: bugzilla-graveyard, Assigned: jaas)

References

()

Details

(Keywords: regression, verified1.9.1, Whiteboard: p-safari)

Attachments

(2 files)

The page has enough content to scroll, but there's no scrollbar anywhere in the browser window with the latest trunk build. Haven't tried branch yet.
Same in Minefield, but fine on branch.

Please kick to the relevant Core component (if it's Layout, you'll need a minimized testcase before setting to NEW) ;)
Version: unspecified → Trunk
<meta http-equiv="MSThemeCompatible" content="no">
Kills the scrollbar completely.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file test case
you should see scrollbars on this page...
see also Camino bug 322218 (form controls)
Assignee: nobody → joshmoz
Component: Page Layout → Widget: Cocoa
Flags: blocking1.9?
Product: Camino → Core
QA Contact: page.layout → cocoa
See, specifically, bug 322218 comment 10 through 12.

At this point, I'd further argue that since our form widget impl now performs auto-fallback when styled appropriately, there's no need to honor a Windows declaration to get generic-looking widgets.

Further, Safari 3 renders both the scrollbar on philippe's testcase properly, as well as renders the button and select from attachment 208265 [details] (my testcase from bug 322218) as normal Aqua button and normal Aqua select.
Blocks: 370439
Summary: Scrollbars missing → Scrollbars missing due to <meta http-equiv="MSThemeCompatible" content="no">
Here is anther site affected (quite popular among web developers):
http://www.positioniseverything.net/


(I've emailed John about it)
(In reply to comment #5)

As far as I can tell, WebKit doesn't support that MS thingie, not does Opera Mac.
Maybe I don't know enough about this ms-tag, but this doesn't seem like a blocker to me.
Flags: tracking1.9+
Flags: blocking1.9?
Flags: blocking1.9-
Flags: tracking1.9+ → wanted1.9.0.x+
For reference: bug 247161 for similar issues on Windows
Still no scroll bars in latest mac code of 3/16/08 - Scroll Bars are in 3/13/08 Mac Code - Using latest Proto theme 0.12.2 - 

(In reply to comment #9)
> Still no scroll bars in latest mac code of 3/16/08 - Scroll Bars are in 3/13/08
> Mac Code - Using latest Proto theme 0.12.2 - 

Yes, that's why this bug is still NEW. We don't need further confirmation that it still exists.

Please read

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

before commenting further.
(In reply to comment #9)
> Still no scroll bars in latest mac code of 3/16/08 - Scroll Bars are in 3/13/08
> Mac Code - Using latest Proto theme 0.12.2 - 

Ray, this bug is something that has existed forever, and it only affects certain pages.  If you're really not seeing scrollbars (everywhere?), and they stopped working between 13-Mar and 16-Mar, you're seeing some other bug (probably a bug in a third-party theme that hasn't been updated for bug 395454, since both today's Minefield and today's Camino show scrollbars otherwise).

If you believe you've discovered another bug in Firefox/Gecko (and not a third-party theme) wherein scrollbars stopped displaying in the past 3 days, you should file a separate bug report on it, with detailed instructions (and URLs) that explain how to reproduce it.
Priority: -- → P3
(In reply to comment #11)
> Ray, this bug is something that has existed forever, and it only affects

"forever" = "since we replaced native scrollbars with fake ones", in case someone comes along and reads that and thinks it means this bug is not a regression.
Whiteboard: p-safari
This bug is still annoying noticeable in firefox 3.0. It was not noticeable on preciously versions. Why is this behaviour changed? Opera, IE and Safari are not related to this typical firefox behavior. Is there any change  this bug is being dealt with?
Flags: blocking1.9.1?
This is a regression but not from Gecko 1.9.0 where we didn't block on this. I'd like to see a fix but I don't see us blocking on this for 1.9.1 either.
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
We don't block on this for Gecko 1.9.0 because of tightened criteria. That criteria should have absolutely nothing to do with blocking on 1.9.1. Re-nominating based on that, though I'm guessing it'll just get minused again...
Flags: blocking1.9.1- → blocking1.9.1?
Yeah, given our "once we ship a bug we'll never bother really fixing it" policy...
(In reply to comment #17)
> Yeah, given our "once we ship a bug we'll never bother really fixing it"
> policy...

That's untrue and unfair, ignoring a lot of hard work that we do to fix bugs for users after a release. We certainly are constrained by resources though, I realize that is frustrating. This bug has been on our radar for a while and we'll fix it as soon as priorities allow.
Attached patch fix v1.0Splinter Review
Anyway, here's a fix I'm at least happy with for the time being. It does the same thing WebKit does. It seems we don't have CSS set up to render non-native scrollbars in content on Mac OS X (they don't even get a size), so when MSThemeCompatible=no disables theme support for the pres shell we're screwed for scrollbars. This just excludes scrollbars from honoring disabled theme support on Mac OS X.

We should file another bug on getting non-themed scrollbars working in content on Mac OS X, and when that is fixed we can remove this. I hear Songbird has this working, maybe they can tell us what they did. In any case, we should probably just take this patch for now.
Attachment #346930 - Flags: review?(mstange)
Josh, thank you very much for patching this!
Attachment #346930 - Flags: review?(mstange) → review+
Attachment #346930 - Flags: superreview?(bzbarsky)
Attachment #346930 - Flags: superreview?(bzbarsky) → superreview+
Attachment #346930 - Flags: approval1.9.1b2?
Comment on attachment 346930 [details] [diff] [review]
fix v1.0

a=beltzner
Attachment #346930 - Flags: approval1.9.1b2? → approval1.9.1b2+
Flags: blocking1.9.1? → blocking1.9.1+
Pushed: http://hg.mozilla.org/mozilla-central/rev/c299c47ffbc7
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2
I filed bug 464876 about supporting non-themed scrollbars on Mac OS X.
Has this patch baked long enough to request approval for 1.9.0.x (it's marked wanted for that branch)?
I don't think we should take it on that branch any more. Since I apparently marked it as wanted there I undid that.
Flags: wanted1.9.0.x+
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
rv:1.9.1b3pre) Gecko/20090130 Shiretoko/3.1b3pre Ubiquity/0.1.5 and 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre)
Gecko/20090130 Minefield/3.2a1pre
Status: RESOLVED → VERIFIED
This bug still appears in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10

I had to add <!--[if IE]> .. <![endif]--> tags around the MSThemeCompatible meta tag in order to get scrollbars working in our store.
That's correct.  This will not be fixed in any of the 3.0.x releases; the fix will be in 3.5.  See comment 24 and comment 25.
See Also: → 966240
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: