Elements (TEXTAREA, IFRAME, DIV, etc.) with visibility:hidden still show scrollbars

RESOLVED FIXED

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
15 years ago
7 years ago

People

(Reporter: u62172, Assigned: cbarrett)

Tracking

({classic, pp, testcase})

Trunk
PowerPC
Mac OS X
classic, pp, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [READ comment 69 before commenting; fix will be in Firefox 3/Gecko 1.9])

Attachments

(9 attachments, 2 obsolete attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030101
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030101

The following code produces just scrollbars on a page which is otherwise blank.
It should be totally blank until the Layer is made visible. 

<html>
<head>
<title></title>
</head>
<body>
<div id="Layer1" style="position:absolute; left:99px; top:49px; width:239px;
height:24px; z-index:4; visibility: hidden">
  <form name="form1" >
    <textarea name="HelpText">Some text that is too big for the textarea and
should produce scrollbars when visible.</textarea>
  </form>
</div>
</body>
</html>

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

15 years ago
Created attachment 110489 [details]
scrollbars for hidden block is visible

Comment 2

15 years ago
I see blank page on WinXP. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.3b) Gecko/20021230.
Whiteboard: DUPEME

Comment 3

15 years ago
Created attachment 114942 [details]
Revised testcase, removing absolute positioning not necessary to demonstrate problem
Attachment #110489 - Attachment is obsolete: true

Updated

15 years ago
Attachment #114942 - Attachment description: Updated testcase, removing absolute positioning not necessary to demonstrate problem → Revised testcase, removing absolute positioning not necessary to demonstrate problem

Comment 4

15 years ago
Confirmed using FizzillaMach/2003021903.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Scrollbars visible for hidden textarea → TEXTAREA with visibility:hidden still shows parts of scrollbar
Whiteboard: DUPEME
This worksforme in a current trunk build.  Is this still an issue?

Comment 6

13 years ago
Problem still evident to me viewing attachment 114942 [details] using
FizzillaMach/2004-02-25-05-trunk and Camino/2004-02-25-08.

Aha, only evident using native form controls (i.e., Classic theme). Not evident
using Mozilla's Modern theme.
Keywords: classic
Sounds like a mac-only problem, then.  I'm not seeing this on Linux with any
theme (gtk1 build, though, so none of that native theming stuff).
Keywords: pp

Comment 8

13 years ago
Simon, Pink, any thoughts on this?

Comment 9

13 years ago
Native form control issue.
I wonder whether the problem is the Mac native scrollbar frame not properly
checking its visibility, or the CSS visibility not being inherited properly into
the scrollbar. If the latter I'd expect to see it cross-platform...

Comment 11

13 years ago
*** Bug 237063 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Summary: TEXTAREA with visibility:hidden still shows parts of scrollbar → TEXTAREA & IFRAME with visibility:hidden still show scrollbars

Comment 12

13 years ago
*** Bug 236000 has been marked as a duplicate of this bug. ***

Comment 13

13 years ago
See also bug 234830.

Comment 14

13 years ago
Extra confirmation, encountered recently: 

Gecko Mac OSx, contemporary versions tested: 
20040206 (FireFox) 
20030624 (Netscape) 
20040113 (Mozilla) 

Not a problem on Windows versions. 

My problem code (like 236000) for a select "multi" will hide the select box 
contents per the hidden div, but the scroll bar will always show. 

<DIV id="D1" style="visibility:hidden;"> 
<SELECT name="x" size="4" multiple> 
<OPTION value="1">test</OPTION> 
</SELECT> 
</DIV>

Comment 15

13 years ago
*** Bug 249186 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Summary: TEXTAREA & IFRAME with visibility:hidden still show scrollbars → Elements (TEXTAREA, IFRAME, DIV, etc.) with visibility:hidden still show scrollbars

Comment 16

13 years ago
*** Bug 249179 has been marked as a duplicate of this bug. ***

Comment 17

13 years ago
*** Bug 248598 has been marked as a duplicate of this bug. ***
*** Bug 252507 has been marked as a duplicate of this bug. ***

Comment 19

13 years ago
Not surprisingly, this bug also occurs in the latest built of Camino (2004072608). Considering it was 
already reported in January 2003, it looks as if it's not considered an important glitch. A pity, as it 
destroys the looks of our site in a few of the best browsers for OS X...

http://ip30.eti.uva.nl/bis/insecten.php

Comment 20

13 years ago
Additional comment: to circumvent this Mozilla/Firefox/Camino bug, instead of using visibilty: visible/
hidden, try using display: block/none. For us, this workaround solved the scrollbar bug.

Comment 21

13 years ago
that workaround breaks in IE. so you end up having to use both methods to get
things to hide show properly.

Comment 22

13 years ago
*** Bug 226318 has been marked as a duplicate of this bug. ***

Comment 23

13 years ago
*** Bug 280396 has been marked as a duplicate of this bug. ***

Comment 24

13 years ago
Created attachment 173226 [details]
scrollbars hidden div, in mac-firefox 1.0

Comment 25

12 years ago
Bug 209706 looks like a dup and has a patch

Comment 26

12 years ago
*** Bug 283661 has been marked as a duplicate of this bug. ***

Comment 27

12 years ago
*** Bug 288673 has been marked as a duplicate of this bug. ***

Comment 28

12 years ago
*** Bug 291333 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Keywords: testcase

Comment 29

12 years ago
*** Bug 292720 has been marked as a duplicate of this bug. ***

Comment 30

12 years ago
*** Bug 293127 has been marked as a duplicate of this bug. ***

Comment 31

12 years ago
(In reply to comment #21)
> that workaround breaks in IE. so you end up having to use both methods to get
> things to hide show properly.


I have created a workaround for this bug. It is as follows:

First sniff the brower/platform combination and create a variable that is set 
to true if the event occurs.

	var macFirefoxAlert = false;
	if ((is_fx) && (is_mac)){
		macFirefoxAlert = true;
	}

Then query this variable in your page that has the <div> tag element, and set 
it to change the overflow:auto to overflow:hidden as an onload event

<script language="javascript">
	if (macFirefoxAlert){
	document.getElementById('yourDivTagIdGoesHere').style.overflow 
= "hidden";
	}
</script>


Then call one of two functions when you open/close the <div> tag itself, and 
pass the name of the tag over, like this:

var macFirefoxScrollerIs = 'nothing';
function showMacFirefoxScroller(divId){
	if (macFirefoxAlert){
	document.getElementById(divId).style.overflow = "auto";
	macFirefoxScrollerIs = divId;
	}
}

function hideMacFirefoxScroller(){
	if (macFirefoxAlert){
		if (macFirefoxScrollerIs != "nothing"){
		document.getElementById(macFirefoxScrollerIs).style.overflow 
= "hidden";
		macFirefoxScrollerIs = 'nothing';
		}
	}
}

So, when your javascript shows your <div>, it should also call 
showMacFirefoxScroller('yourDivTagIdGoesHere')   and when it closes the <div> 
tag (rehides it again) it should also call  hideMacFirefoxScroller()

Hope you find this useful.
Mark

Updated

12 years ago
Depends on: 209706

Comment 32

12 years ago
*** Bug 191265 has been marked as a duplicate of this bug. ***

Comment 33

12 years ago
*** Bug 234830 has been marked as a duplicate of this bug. ***
Created attachment 186939 [details] [diff] [review]
working patch (diff -w)

This is a continuation of the work done in Bug 191265.	In that bug, I had the
code mostly working, except I would get extra scrollbars appearing in the upper
left.  I traced this to extra calls of |nsNativeScrollbar::Paint()|.  So I took
bryner's |mInPaint| idea, but applied it the other way:  we only want the
scrollbar to paint in |nsNativeScrollbar::Paint()| if the event has previously
gone through |nsNativeScrollbar::OnPaint()|.  That got rid of the extra
scrollbars I was seeing.

This patch also fixes events, so they don't go to the scrollbars before going
through the view manager.  But I'm not sure if I handled it correctly.	I added
a |handleMouseEvent()| method to |nsINativeScrollbar|.	Then in
nsNativeScrollbar.cpp, I just have that method call |DispatchMouseEvent()|. 
Not sure if that's the best way to do it.

Patch also adds the event handling code to nativescrollbar.xml, to make it
match scrollbar.xml better.  And finally, the painting code in
nsNativeScrollbarFrame.cpp handles invisible DIVs properly.

If someone copied here who has a Mac could also test this patch out, I'd
appreciate it.
*** Bug 215558 has been marked as a duplicate of this bug. ***

Comment 36

12 years ago
Comment on attachment 186939 [details] [diff] [review]
working patch (diff -w)

With this patch, I'm crashing when clicking on the XUL scrollbars in attachment
186755 [details] of bug 274036. It looks like it's recursing in the scrollbar event
handling code.

Comment 37

12 years ago
It's unclear to me how we can fix Cocoa scrollbars in the same way here. They
live in the widet hierarchy, so can redraw as a result of Cocoa -display
messages, value changes etc. We can probably hide them to fix this bug, but it's
going to be hard to clip them (for example, the testcase in attachment 113711 [details]).
Assignee: layout.form-controls → jhpedemonte
Severity: normal → enhancement

Comment 38

12 years ago
Continuing the Cocoa scrollbar thought: I don't see how we correctly clip native
scrollbars (see attachment 113711 [details]) with our current widget hierarchy. The issue
is that Cocoa draws widgets back-to-front, so we redraw the parent widget (which
draws the text of the second <div> in the testcase), and then its children
(which draws the native scrollbars over the text).

The only ways I can see to make this work are:
1. don't use native scrollbars
2. don't leave the native scrollbars in the widget hierarchy, but shove them in
   only when we want to draw them (expensive?)
3. add an extra widget to render the contents of a widget-with-scrollbars, 
   which is a later subview than the scrollbars, so that it renders afterwards.
Severity: enhancement → normal
4. only do drawing when told by gecko. hyatt has a mechanism that they use in
webcore that doesn't draw native widgets immediately when the toolkit says, but
instead routes the draw request through the layout engine so that it gets
clipped/zordered/etc correctly. it's a pain in the ass, but it works.

Comment 40

12 years ago
(In reply to comment #39)
> 4. only do drawing when told by gecko. hyatt has a mechanism that they use in
> webcore that doesn't draw native widgets immediately when the toolkit says, but
> instead routes the draw request through the layout engine so that it gets
> clipped/zordered/etc correctly. it's a pain in the ass, but it works.

That somewhat kinda like my #2.

I have something like this in my tree right now, but I'm not sure that the views
are being drawn in the right order.

Comment 41

12 years ago
Webkit (in which this works) actually bypasses the default NSView update
machinery to get around this problem. It rips subviews out of a view before
display, then shoves them back in, while letting KHTML draw the subviews at the
correct time. It does this in a override of a private NSView method, and in such
a way that we can't easily do the same on both 10.2 and 10.3.
(In reply to comment #36)
> It looks like it's recursing in the scrollbar event
> handling code.

Before, the events would come in from |nsWindow| into our
|DispatchMouseEvent()|, which would then pass the events on up the chain, where
they would eventually get dispatched to the rest of Gecko.  Since the events are
now coming in from |nsNativeScrollbarFrame| into |nsNativeScrollbar|, we should
just consume the events and not pass them on.

As for the Cocoa issues, bryner had attached some code in his patch to bug
191265.  Is any of that useful?

Updated

12 years ago
QA Contact: tpreston → timeless

Updated

12 years ago
QA Contact: timeless → timeless
Created attachment 190885 [details] [diff] [review]
patch (carbon & cocoa)

This is my previous patch plus bryner's Cocoa changes from bug 191265.	It
makes things better on Camino.	The testcase in this bug correctly shows no
scrollbars.  And the testcase in bug 191265 sometimes draws the scrollbars
below the text.  But there are some drawing issues:  when using the mouse to
scroll, sometimes only the scrollthumb draws (every other part of the scrollbar
becomes white).  Well, you guys know more about Cocoa then I do, so maybe you
can make something out of this.

I also found that if I comment out the [mView enablePainting:NO] line, then
Camino still correctly hides the invisible scrollbars, and the other scrollbars
display properly (no drawing issues).  Of course, we would still have the
problem of scrollbars overpainting DIVs, but I think the most common problem is
that of hidden scrollbars not staying hidden.
Attachment #186939 - Attachment is obsolete: true

Comment 44

12 years ago
*** Bug 301426 has been marked as a duplicate of this bug. ***
*** Bug 299033 has been marked as a duplicate of this bug. ***
*** Bug 302018 has been marked as a duplicate of this bug. ***
Bug 299033 has a nice testcase, also.
*** Bug 294284 has been marked as a duplicate of this bug. ***
*** Bug 302972 has been marked as a duplicate of this bug. ***

Comment 50

12 years ago
*** Bug 303911 has been marked as a duplicate of this bug. ***

Comment 51

12 years ago
This is in relation to Bug 302972 which has been marked as a dugpe of this one.
I ccan now reproduce the scroll bar corruption. it occurs when you have used
spell check and returned to edit mode. Some corruption occurs each time. It will
get worse as the text forces scroll bars to appear and get worse if you spell
check multiple times in a longer document.

Updated

12 years ago
Blocks: 306609
*** Bug 308342 has been marked as a duplicate of this bug. ***

Comment 53

12 years ago
We confirm that this bug has been fixed.

Comment 54

12 years ago
(In reply to comment #53)
> We confirm that this bug has been fixed.

Please test on Firefox and Camino before marking Fixed.

Comment 55

12 years ago
Created attachment 196571 [details]
recent continued scroll bar corruption in gmail

Comment 56

12 years ago
*** Bug 309243 has been marked as a duplicate of this bug. ***
*** Bug 310232 has been marked as a duplicate of this bug. ***
*** Bug 310292 has been marked as a duplicate of this bug. ***

Comment 59

12 years ago
*** Bug 311789 has been marked as a duplicate of this bug. ***
*** Bug 313840 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Flags: blocking1.9a1?

Comment 61

12 years ago
*** Bug 316508 has been marked as a duplicate of this bug. ***

Comment 62

12 years ago
Created attachment 203684 [details]
google scroll bar re-appears outside of gmail -- google home pages

The last few builds have been completely clean, but this appeared today in the nightly 2005111804 (v1.0b1+ This time its not in gmail ... but google's new custom home pages and searches.

df

Comment 63

12 years ago
*** Bug 317765 has been marked as a duplicate of this bug. ***

Comment 64

12 years ago
Created attachment 205021 [details]
scrollbars apear innapropriately (visible instead of invisible) in blogspont.com

2005120304 (v1.0b1+) iBook 1Ghz 640MB Memory OSX 10.3.9,CamiOptions extension.  This happened as I switched editing view in Blogspot. This is the only time it has occured during the few hours I was working on blogSpot.

davidf

Comment 65

12 years ago
scrollbars apear innapropriately:
I found a possible reason: 
Its a problem in the Gecko Engine.
Scrollbars of the last layer in the order they appear in the html are always displayed, even if the layer is invisible.
I had this problem in one file (php) an could solve it reproducable with reordering the layers in the html output.
Thsi appeard in Firefox 1.0.x also.
So its a problem with gecko and not camino, i presume.

Comment 66

12 years ago
*** Bug 322213 has been marked as a duplicate of this bug. ***

Comment 67

12 years ago
Created attachment 208527 [details]
Hidden scroll bar appear in the middle of blogspot edit sessions

2006011404 (v1.0b2+) 1 Ghz iBook, This seems to appear during complex editing sessions where I need to toggle between open application windows

Comment 68

12 years ago
Created attachment 208536 [details]
hidden scroll bars appear in blogspot edit session this time in Deer Park

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060114 Firefox/1.6a1 I attempted editing at blogspot again with a new nightly of Deer Park, the same scroll bar problems appeared in the same place in blog spot. This time I had only one Application window open
Please do not continually post screenshots and comments that the bug is still valid. This is a known bug and that's why it's open.

If you are not a developer working to fix this bug, please vote for this bug and do not post comments.
Whiteboard: [READ comment 69 before commenting]
*** Bug 326406 has been marked as a duplicate of this bug. ***

Comment 71

11 years ago
*** Bug 326844 has been marked as a duplicate of this bug. ***

Comment 72

11 years ago
Scrollbars of page elements draw above / over / on top of ALL other content
http://www.shawnchin.net/scrollbarTest/

Comment 73

11 years ago
Created attachment 211738 [details]
Z-index layering with normal visibility - scrollbar bleeds through

Comment 74

11 years ago
*** Bug 328086 has been marked as a duplicate of this bug. ***
*** Bug 330090 has been marked as a duplicate of this bug. ***

Comment 76

11 years ago
*** Bug 330809 has been marked as a duplicate of this bug. ***

Comment 77

11 years ago
*** Bug 332609 has been marked as a duplicate of this bug. ***
*** Bug 332669 has been marked as a duplicate of this bug. ***

Comment 79

11 years ago
The simplest workaround for this bug is to set your overlying element to overflow:auto. This will keep scrollbars underneath it from bleeding through. If your element *contains* scrollbars, the easiest way to hide them is to set a class on the element when it's invisible, as such:

.hidden * {
   overflow:hidden;
}

Add this class when the element is hidden, and the scrollbars should go away. I also add this CSS class definition to attempt to be 100% certain that hidden scrolling elements are not displayed:

.hidden textarea, .hidden  select {
   overflow:hidden;
   display:none;
}

A little bit of browser sniffing is useful when applying this class, since this issue only affects Gecko on OSX.

Comment 80

11 years ago
*** Bug 334212 has been marked as a duplicate of this bug. ***
*** Bug 321747 has been marked as a duplicate of this bug. ***
Josh, mento, any chance you guys could take a look at the last patch and lend a hand?  You know more about the widgets than I do, and I'm pretty lost in layout.

As I mentioned in comment #43, the patch is working well for hiding scrollbars from 'hidden' DIVs, which seems to be the most common problem.  The hard part is trying to get scrollbars to paint under DIVs.

Comment 83

11 years ago
*** Bug 339458 has been marked as a duplicate of this bug. ***
*** Bug 340614 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Blocks: 339186

Comment 85

11 years ago
*** Bug 343817 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Flags: blocking1.9a1? → blocking1.9+

Comment 86

11 years ago
*** Bug 349199 has been marked as a duplicate of this bug. ***
*** Bug 349400 has been marked as a duplicate of this bug. ***

Comment 88

11 years ago
*** Bug 349772 has been marked as a duplicate of this bug. ***

Comment 89

11 years ago
*** Bug 352670 has been marked as a duplicate of this bug. ***

Comment 90

11 years ago
*** Bug 354990 has been marked as a duplicate of this bug. ***

Comment 91

11 years ago
*** Bug 356386 has been marked as a duplicate of this bug. ***
*** Bug 357285 has been marked as a duplicate of this bug. ***
*** Bug 360760 has been marked as a duplicate of this bug. ***
*** Bug 353134 has been marked as a duplicate of this bug. ***
I don't know if it is related but added to this scrollbar bug, it seems that the select box does not report correct clientWidth. It does not include the width of the scrollbar (so when you try to overlay the control, the scollbar is visible and the overlay is too short to hide it).

Tested on firefox 2.0/os x 10.4.8

Comment 96

11 years ago
*** Bug 362608 has been marked as a duplicate of this bug. ***

Comment 97

11 years ago
*** Bug 326440 has been marked as a duplicate of this bug. ***

Comment 98

11 years ago
*** Bug 363939 has been marked as a duplicate of this bug. ***

Updated

11 years ago
Duplicate of this bug: 368749

Comment 100

10 years ago
For clarity, this bug affects all elements w/scrollbars, visible or not.  Firefox on Mac simply can't display anything overlapping w/scrollbars without them bleeding through (barring occasional remedies like overflow settings that sometimes help).  For anyone trying to create web apps with multiple windows this make the Mac almost unusable w/Firefox.  Forcing all background windows off the screen, etc., is not viable for these types of apps, because it's perfectly valid for windows to overlap each other.  Google this issue and you'll find thousands of frustrated developers.  Just throwing my vote in to humbly beg for attention to this bug.  Thanks much for all you guys do.

Comment 101

10 years ago
This should be fixed when bug 370439 lands.
Depends on: 370439

Comment 102

10 years ago
(In reply to comment #101)
> This should be fixed when bug 370439 lands.

Is that expected soon?
Duplicate of this bug: 374498

Updated

10 years ago
Duplicate of this bug: 354761

Updated

10 years ago
Duplicate of this bug: 374916

Updated

10 years ago
Duplicate of this bug: 377425

Updated

10 years ago
Duplicate of this bug: 378952

Comment 108

10 years ago
This bug affects most XHTTP web applications because all scrollbars (TEXTAREA, IFRAME, SELECT multiple, etc.) shine thru overlaying layers. Reminds me to the old IE <= 6 SELECT-BOX bug.
See OS X 10.4.9 - Gecko/20070309 Firefox/2.0.0.3 examples:
http://www.syncbyte.com/misc/opacitybug.html
http://www.syncbyte.com/misc/opacitybug.png

Hope this bug will be fixed soon
(Assignee)

Comment 109

10 years ago
fixed by 370439
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Per comment 109, this bug will be fixed in Firefox 3. You can download a trunk nightly to test the fix.
Duplicate of this bug: 378981

Updated

10 years ago
Assignee: jhpedemonte → cbarrett

Updated

10 years ago
Duplicate of this bug: 380890

Comment 113

10 years ago
The "scrollbar fix" has not been fixed for http://www.thorlabs.com/Navigation.cfm?pageRef=8.

Comment 114

10 years ago
Yes it has; you are using branch Camino, and this is a trunk-only fix. This fix won't appear in a released Camino version until Camino 2.0.

Comment 115

10 years ago
(In reply to comment #114)
> Yes it has; you are using branch Camino, and this is a trunk-only fix. This fix
> won't appear in a released Camino version until Camino 2.0.
> 

Sorry I didn't understand that.  I just used the most recent night build to test it.  Thanks.

Updated

10 years ago
Duplicate of this bug: 383703

Updated

10 years ago
Duplicate of this bug: 386946

Updated

10 years ago
Duplicate of this bug: 386859

Comment 119

10 years ago
Does not seem to be working?

http://bustophersbarbistro.co.uk/restaurant

Tried in:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5

Can't tell from here what version the Trunk is - maybe you want to put that up there this is not the latest version - not a developer so not downloaded nightly builds thankyou

(Assignee)

Comment 120

10 years ago
(In reply to comment #119)
> Does not seem to be working?
> 
> http://bustophersbarbistro.co.uk/restaurant
> 
> Tried in:
> 
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.5)
> Gecko/20070713 Firefox/2.0.0.5
> 
> Can't tell from here what version the Trunk is - maybe you want to put that up
> there this is not the latest version - not a developer so not downloaded
> nightly builds thankyou

This fix will be in Firefox 3. It won't be in any of the Firefox 2 releases, so you'll have to wait until Firefox 3 is out.
Whiteboard: [READ comment 69 before commenting] → [READ comment 69 before commenting; fix will be in Firefox 3/Gecko 1.9]

Updated

10 years ago
Duplicate of this bug: 390654

Updated

10 years ago
Duplicate of this bug: 393521

Updated

10 years ago
Duplicate of this bug: 398341

Updated

10 years ago
Duplicate of this bug: 402786

Updated

10 years ago
Duplicate of this bug: 403382

Updated

10 years ago
Duplicate of this bug: 405294

Updated

10 years ago
Duplicate of this bug: 406844

Updated

9 years ago
Duplicate of this bug: 415064
Duplicate of this bug: 306609
Duplicate of this bug: 499599

Updated

8 years ago
Duplicate of this bug: 507752
Duplicate of this bug: 397174

Updated

8 years ago
Duplicate of this bug: 380652
Duplicate of this bug: 260753

Comment 135

7 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=280661

Comment 136

7 years ago
Comment on attachment 173226 [details]
scrollbars hidden div, in mac-firefox 1.0

I'm not sure if this is the same thing but my scroll bar doesn't show up in Yahoo eMail's upper box, but it does in gmail and the lower Yahoo email box.
You need to log in before you can comment on or make changes to this bug.