Closed Bug 114850 Opened 23 years ago Closed 19 years ago

scrollbars permanently hidden; window.scrollbars.visible = false;

Categories

(Core :: CSS Parsing and Computation, defect, P1)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: paul, Assigned: martijn.martijn)

References

Details

(Keywords: fixed1.8.1, testcase)

Attachments

(3 files)

even simpler testcase.
698 bytes, text/html
Details
testcase with enableprivilege
1014 bytes, text/html
Details
patchv1
1.27 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
bzbarsky
: approval-branch-1.8.1+
dveditz
: approval1.8.0.1-
Details | Diff | Splinter Review 
Setting the body overflow:hidden in style hides the scrollbar in all tabbed
pages and even in the same tab when you continue to browse.
Status: UNCONFIRMED → NEW
Ever confirmed: true
can you be more specific. For me, a document with 
<body style="overflow:hidden;"> shows the scrollbars
in a current trunk build on win2k, in either tabbed 
mode or normal mode.
You're right. The problem lies not in the overflow but in the javascript:
window.scrollbars.visible = false; i used this script to hide the main scrollbar
and to only show the scrollbar in the div element.

Check example at: http://www.oww.net/bugzilla/moztest.html

and then click the link to show no scrollbar on other sites as well.
Attached file even simpler testcase. — 

    
    

    
  
Hmm, yep. Setting body{overflow:hidden;} and window.scrollbars.visible=false
permanently disables the scrollbar for a window, even when you load other 
documents.

Not really sure what is happening. However, one thing that is wrong is that,
I believe, window.scrollbars.visible requires UniversalBrowserWrite to set 
the value, but apparently we are letting anyone set the value.
Summary: ccs2 style body overflow:hidden hides scrollbar in all tabs → scrollbars permanently hidden; body {overflow:hidden} && window.scrollbars.visible = false;

    
  

        Attachment #61627 -
        Attachment mime type: text/plain → text/html

    
    

    
  
Reassigning to new component owner.

Assignee: hyatt → jaggernaut

    
    

    
  
-> style system, not a tabbed browser bug.
Assignee: jaggernaut → dbaron
Component: Tabbed Browser → Style System
QA Contact: sairuh → ian

    
    

    
  
Not platform specific bug. Nominating.

Also is it not necessary to specify the body {overflow:hidden } css style at all.

Is the correct solution to disable the writing window.scrollbars.visible on non
new windows? Or would be a better solution to reset the property after each
reload/navigation?
Keywords: mozilla1.0
OS: Windows 2000 → All
Hardware: PC → All
Summary: scrollbars permanently hidden; body {overflow:hidden} && window.scrollbars.visible = false; → scrollbars permanently hidden; window.scrollbars.visible = false;

    
    

    
  
Who invented window.scrollbars, and why?  (...and shouldn't that person own this
bug?)

    
    

    
  
Please don't remove it. I use it in several of my scripts. :-) 
Keywords: testcase
Severity: normal → major
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla1.1alpha

    
    

    
  
cc'ing myself

    
    

    
  
window.scrollbars has danm's name all over it (bug 111524).

->danm
Assignee: dbaron → danm
Status: ASSIGNED → NEW
Target Milestone: mozilla1.1alpha → ---

    
    

    
  
i see this on win2000 build id : 2002-07-31-08-1.0branch


    
    

    
  
So if nothing else we should reset scrollbars to visible in
GlobalWindowImpl::SetNewDocument.  That doesn't solve the multiple-tab problem,
however...

    
    

    
  
This also happens on current Firefox builds on Linux. Would be nice, if somebody
could confirm the bug...

    
  
Assignee: danm.moz → nobody

    
    

    
  
Why is it considered a bug?
Isn't this property analogous to window.statusbar, window.toolbar, etc?
http://www.mozilla.org/docs/dom/domref/dom_window_ref104.html#1020687
It definetely should require UniversalBrowserWrite privileges to be able to use it, though.

    
    

    
  
> Why is it considered a bug?

Because one site can affect whether scrollbars appear on another one.

Want to whip up a patch to make this require UniversalBrowserWrite?  That would resolve this bug.
Keywords: helpwanted

    
    

    
  


  

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patchv1
        — 
          — Splinter Review
      

    


  
So like this, I guess.
Shouldn't Mozilla throw a js error when no enablePrivilege is set for window.scrollbars.visibility, window.statusbar.visibility, etc?
Currently Mozilla just fails silently.

        Attachment #207038 -
        Flags: review?(bzbarsky)

    
    

    
  
Comment on attachment 207038 [details] [diff] [review]
patchv1

r+sr=bzbarsky.  If we threw, that would break scripts that try to do this, but this is really not a fatal error...

        Attachment #207038 -
        Flags: superreview+

        Attachment #207038 -
        Flags: review?(bzbarsky)

        Attachment #207038 -
        Flags: review+

    
  
Assignee: nobody → martijn.martijn

    
    

    
  
mozilla/dom/src/base/nsBarProps.cpp; new revision: 1.27; previous revision: 1.26
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha

    
  

        Attachment #207038 -
        Flags: approval1.8.1?

        Attachment #207038 -
        Flags: approval1.8.0.1?

    
    

    
  
Comment on attachment 207038 [details] [diff] [review]
patchv1

a- for 1.8.0.x, the 1.8.1 branch is currently using trunk checkin rules

        Attachment #207038 -
        Flags: approval1.8.0.1? → approval1.8.0.1-

    
  

        Attachment #207038 -
        Flags: approval1.8.1? → branch-1.8.1?(bzbarsky)

        Attachment #207038 -
        Flags: branch-1.8.1?(bzbarsky) → branch-1.8.1+

    
    

    
  
Fixed on the 1.8.1 branch.
Keywords: helpwanted → fixed1.8.1

    
    

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

    
    

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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: