Closed Bug 340270 Opened 18 years ago Closed 18 years ago

Horizontal scrollbar disabled for div within div with differing direction styles

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 6976

People

(Reporter: avaley, Unassigned)

Details

(Keywords: testcase)

Attachments

(4 files)

Testcase #1
(deleted), text/html
Details
wip
(deleted), patch
Details | Diff | Splinter Review
Testcase #2
(deleted), text/html
Details
Rendering of Testcase #2 (with patch)
(deleted), image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

scrollbar ltr rtl disabled overflow-x

Reproducible: Always

Steps to Reproduce:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
	<title>Untitled Page</title>
	<style type="text/css">
		<!--
		.dirblock
		{
			padding:5px;
			border:double 1px green;
		}
		.wrapper
		{
			width:500px;
			padding:1px;
			border:solid 1px blue;
			/* Note: changing to overflow:scroll is not any better in regards to enabling the scrollbars*/
			overflow-x:scroll;
			overflow-y:hidden;
			direction:inherit;
		}
		.wrapped
		{
			width:1500px;
			border:solid 1px red;
		}
		// -->
		</style>
</head>

<body>

<div class="dirblock" style="direction:ltr;">ltr block
	<div class="wrapper">
		<div class="wrapped" style="direction:ltr;">ltr div within an ltr div</div>
	</div>
	<br />
	<div class="wrapper">
		<div class="wrapped" style="direction:rtl;">rtl div within an ltr div</div>
	</div>
</div>

<br />

<div class="dirblock" style="direction:rtl;">rtl block
	<div class="wrapper">
		<div class="wrapped" style="direction:rtl;">rtl div within an rtl div</div>
	</div>
	<br />
	<div class="wrapper">
		<div class="wrapped" style="direction:ltr;">ltr div within an rtl div</div>
	</div>
</div>

</body>
</html>
Actual Results:  
Second and third divs are disabled; fourth div is correct, but initial scroll position does not show content.

Expected Results:  
All scrollbars to be enabled, for the initial scroll position to be based on the direction of the outer div and the inner text to be aligned according to its direction (this is OK).

Could not find issue (although I might have missed it when searching).  Is there a work around?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060603 Minefield/3.0a1
In trunk the second and the fourth scrollbar are disabled. The third scrollbar works.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → 1.8 Branch
Attached file Testcase #1 (deleted) — 
Reporter's testcase from comment 0
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
OS: Windows Server 2003 → All
Version: 1.8 Branch → Trunk
I'm pretty sure the current behavior on trunk is by design. You can't scroll beyond the point of origin (meaning you cant scroll to the left of the origin in LTR, or to the right in RTL). See e.g. bug 192767 comment #18.

So I would consider this a dupe of bug 192767 (now fixed).
When a scrolling mechanism is provided, surely it should allow you to view
all content that was clipped. At least that seems to be the implicit intent
of text in the spec. http://www.w3.org/TR/CSS21/visufx.html#propdef-overflow

(In reply to comment #4)
> When a scrolling mechanism is provided, surely it should allow you to view
> all content that was clipped. At least that seems to be the implicit intent
> of text in the spec. http://www.w3.org/TR/CSS21/visufx.html#propdef-overflow
> 

This was already brought up as an argument in bug 6976 comment 109. The bug was nevertheless WONTFIXed. See bug 6976 comment 117 (and the rest of the discussion on bug 6976, although it's very long and often diverts from the topic).
Rather a duplicate of 

*** This bug has been marked as a duplicate of 6976 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
While I have sympathy for the reason to wontfix it (bug 6976 comment 117),
I still think it's incorrect behaviour.
Could we perhaps limit it to the viewport and allow scrolling in other cases?
Attached patch wip (deleted) — — Splinter Review 
For example like this?
That was "a further reason".  The main reason was bug 6976 comment 38.
But bug 6976 comment 38 is just a comment on how to implement it properly
noting that a starting point in the middle would seem "weird" to most users.
I don't see how that is an argument for the current behaviour of not being
able to scroll at all even when the author specifies overflow:scroll.

I find it more useful to provide a functioning scrolling mechanism, even if the
starting position is "weird" it still allows me to view the content.
(and we should fix the starting position of course)

How do you propose just "fix"ing the starting position?

However you may interpret that comment, the fact that there's no good user interface for returning scrollbars whose default position is in the middle to their default position is the main reason I stand by the WONTFIX.  Scrollbars in current operating environments are a limited scrolling mechanism in that they only make sense when the default is at one end or the other; otherwise there's no way for the user to return to the default.
I need to look at the code in more detail to be able to propose a fix.
BTW, when viewing the testcase with the attached patch applied, the scrollbars
are in fact positioned at the end positions as would be expected on load...
So how would this starting position problem manifest itself?

My point is that having a slightly weird scrollbar is better than having
no scrollbar at all for the time being. I don't think fixing the starting
position should block this.
The problem has nothing to do with code, and it's not temporary.  The problem is that once the user scrolls, there's no convenient way to get back to the starting point, which is usually where the vast majority of the text is.
I don't understand what you mean by "convenient way to get back to the
starting point". I haven't seen any problems with using the scrollbars with
the patch so far.
If overflow is in both directions, which you propose allowing, how does the user get back to the starting point?
Attached file Testcase #2 (deleted) — 

    
    

    
  
I would guess that in practice the visual rendering of the content itself
will provide the necessary orientation of where that is.

I tried the patch with negative vertical overflow and the Home key positions
the scrollbar so that the view starts at the normal flow origin.
I'm not sure if there is a key combination to do the same horizontally.

    
    

    
  
(In reply to comment #18)
> I would guess that in practice the visual rendering of the content itself
> will provide the necessary orientation of where that is.

Users who aren't twenty-something years old might not have the manual dexterity or skill with scrollbars to do this easily.

> I'm not sure if there is a key combination to do the same horizontally.

Home used to restore both horizontally and vertically; if we do this we definitely need to undo the change that made it leave the horizontal position untouched.

    
    

    
  
(In reply to comment #19)
> Users who aren't twenty-something years old might not have the manual
> dexterity or skill with scrollbars to do this easily.

I still think that is a minor problem compared with clipping the content.

> Home used to restore both horizontally and vertically...

Looks like bug 163562 fixed that, see also bug 292074

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: