Closed Bug 187435 Opened 21 years ago Closed 17 years ago

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

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: u62172, Assigned: cbarrett)

References

Details

(Keywords: classic, platform-parity, testcase, Whiteboard: [READ comment 69 before commenting; fix will be in Firefox 3/Gecko 1.9])

Attachments

(9 files, 2 obsolete files)

Revised testcase, removing absolute positioning not necessary to demonstrate problem
434 bytes, text/html
Details
scrollbars hidden div, in mac-firefox 1.0
67.66 KB, application/pdf
Details
patch (carbon & cocoa)
23.93 KB, patch
Details | Diff | Splinter Review
recent continued scroll bar corruption in gmail
46.46 KB, image/jpeg
Details
google scroll bar re-appears outside of gmail -- google home pages
150.10 KB, image/jpeg
Details
scrollbars apear innapropriately (visible instead of invisible) in blogspont.com
93.45 KB, image/jpeg
Details
Hidden scroll bar appear in the middle of blogspot edit sessions
43.94 KB, image/jpeg
Details
hidden scroll bars appear in blogspot edit session this time in Deer Park
69.39 KB, image/jpeg
Details
Z-index layering with normal visibility - scrollbar bleeds through
213.74 KB, image/png
Details 
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.
Attached file scrollbars for hidden block is visible (obsolete) — 

    
    

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

    
  

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

    
    

    
  
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?

    
    

    
  
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

    
    

    
  
Simon, Pink, any thoughts on this?

    
    

    
  
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...

    
    

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

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

    
    

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

    
    

    
  
See also bug 234830.

    
    

    
  
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>

    
    

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

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

    
    

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

    
    

    
  
*** Bug 248598 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 252507 has been marked as a duplicate of this bug. ***

    
    

    
  
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

    
    

    
  
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.

    
    

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

    
    

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

    
    

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

    
    

    
  
Bug 209706 looks like a dup and has a patch

    
    

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

    
    

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

    
    

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

    
  
Keywords: testcase

    
    

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

    
    

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

    
    

    
  
(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
Depends on: 209706

    
    

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

    
    

    
  
*** Bug 234830 has been marked as a duplicate of this bug. ***

    
    

    
  

      
      
      
      

        Attached patch
          
          
        working patch (diff -w) (obsolete)
        — 
          — Splinter Review
      

    


  
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 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.

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
(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.

    
    

    
  
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?



    
  
QA Contact: tpreston → timeless

    
  
QA Contact: timeless → timeless

    
    

    
  


  
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

    
    

    
  
*** 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. ***

    
    

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

    
    

    
  
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.

    
    

    
  
*** Bug 308342 has been marked as a duplicate of this bug. ***

    
    

    
  
We confirm that this bug has been fixed.

    
    

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

Please test on Firefox and Camino before marking Fixed.

    
    

    
  
*** 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. ***

    
    

    
  
*** Bug 311789 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 313840 has been marked as a duplicate of this bug. ***

    
  
Flags: blocking1.9a1?

    
    

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

    
    

    
  


  
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

    
    

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

    
    

    
  


  
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

    
    

    
  
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.

    
    

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

    
    

    
  


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

    
    

    
  


  
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. ***

    
    

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

    
    

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

    
    

    
  
*** Bug 328086 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 330090 has been marked as a duplicate of this bug. ***

    
    

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

    
    

    
  
*** Bug 332609 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 332669 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
*** 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.

    
    

    
  
*** Bug 339458 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 340614 has been marked as a duplicate of this bug. ***

    
  
Blocks: tibco

    
    

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

    
  
Flags: blocking1.9a1? → blocking1.9+

    
    

    
  
*** Bug 349199 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 349400 has been marked as a duplicate of this bug. ***

    
    

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

    
    

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

    
    

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

    
    

    
  
*** 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

    
    

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

    
    

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

    
    

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

    
    

    
  
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.


    
    

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

    
    

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

Is that expected soon?

    
    

    
  
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

    
    

    
  
fixed by 370439
Status: NEW → RESOLVED
Closed: 17 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.
Assignee: jhpedemonte → cbarrett

    
    

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

    
    

    
  
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.

    
    

    
  
(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.

    
    

    
  
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



    
    

    
  
(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]

    
    

    
  
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.