Closed Bug 356838 Opened 18 years ago Closed 18 years ago

placing the vertical scrollbar on the left does not work

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Version:
1.8 Branch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 265276

People

(Reporter: mscam_de, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Maxthon; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: FireFox-2 RC

On a page with frames/iframes, the frame can have its own scrollbar
If the screen is not wide enough to display the whole of the frame, the frame's scrollbars may not be visible.
There is a workabout for that, that works for Internet explorer/Maxthon, but not in Firefox and some others:

<body id="xxx"  style="direction:rtl">   <div style="direction:ltr">
....
</div>
</body>

Through this little trick the web-author can ensure, that the frame's vertical scrollbar is always visible.


Reproducible: Always

Steps to Reproduce:
1.load www.rakovszky.info
2. click on Site-Help in the Links-Table on the left
3.

Actual Results:  
The frame's scrollbar is on the right-hand side and may not be visible.



Expected Results:  
Load Maxthon (or IE) and do steps 1. and 2. to see how it should look like. (Asking for coloured scrollbars in FF may be too much. But it helps to distinguish between that of the browser and that of the page/frame.)


This trick may or may not be covered by the official specifications, but is a very useful one, especially when considering that some users may use a low-resolution screen.
I expect, FF has the ability to display the scrollbar on the left, thus making this trick (?) work could be a very simple modification:
Decide place of the scrollbar at the body-level, ignore any subsequent "direction"-change as far as the scrollbar is concerned.

*** This bug has been marked as a duplicate of 221396 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
I am not talking about the main scrollbar of the browser, but internal scrollbars within frames, so it is not the same, just a similar bug.

So treat this as a separate bug. A frame is not the browser. Arguments used in 221396 do not apply here. 
Of course the FF developers are free to implement a special property, that places the scrollbar on the left-side (right side for non-european languages).
That will not disturb advanced web-authors who already cater for diversities in he browsers.

If IE (and Maxthon) can do it, why is the childish argument in 221396 against it.
I have read that theoretical argument, and it does not wash with me. 
A scrollbar that is not visible is just idiotic, useless. 
Is Firefox a browser for its users (and web authors) or just a plaything of some dedicated programmers. (I am also such a person.) If it can be done, it should be done. It is not for the Firefox authors to dictate how the web-authors should develop their sites, or imposing a straightjacket on the user.
They should cater for various solutions.
If they refuse to do so, if they behave as little gods (see 221396) then Web-authors will warn their users to use another browser and Firefox will be dead as a duck.

The developers of FireFox are not MASTERS but servants of Web-developers.
Firefox must be able to display anything which is written according to W3C specifications. For borderline-cases, the usability of web-sites and not their eventual stretching of specifications should be the rule.

If it stays at the status "Resolved- Wontfix" I have no option, but recommend the use of another browser than Firefox, quoting the arguments above.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
The argument given in bug 221396 applies equally to internal frames as to the main webpage in my opinion.
Component: General → Layout: BiDi Hebrew & Arabic
Product: Firefox → Core
QA Contact: general → layout.bidi
Version: unspecified → 1.8 Branch
This problem applies to any language.
As long, as the standard screen-size was something like 800x640, the pages were designed for these.
But now 1200x1024 or even larger are becomming standard, but some people se other sizes (and soon extra-wide monitors will be used), it is important, that there is a way to place the frame-scrollbar so that it is always visible.
Out-of-sight = out-of-mind.
The browser scrollbar is (say) always on the right side.
The reader may forget, that there is another, for him invisible, scrollbar that applies to the frame.
This is why a frame-scrollbar on the left is very useful.
I had a lot of problems with the usability of my own home-page, until I found this solution on the net.

Thus, although it is currently in the Hebrew & Arabic section, it should be moved at the first opportunity to the core to show, that it is useful for all languages (and of course avoiding a possible complaint about race-discrimination).

It would be nice if W3C would define a simple construct, that would allow a horizontal scrollbar anywhere within the page (analog to <hr>), thus allowing web-designers to make certain, that by extra-wide pages a horizontal scrollbar is always visible.

> Thus, although it is currently in the Hebrew & Arabic section, it should be
> moved at the first opportunity to the core to show, that it is useful for all
> languages (and of course avoiding a possible complaint about
> race-discrimination).

BiDi Hebrew & Arabic appears to be the only component for rtl issues.

> 
> It would be nice if W3C would define a simple construct, that would allow a
> horizontal scrollbar anywhere within the page (analog to <hr>), thus allowing
> web-designers to make certain, that by extra-wide pages a horizontal scrollbar
> is always visible.

Can you clear up what you mean here. Is this bug about the failure for the vertical scrollbar to appear on the left in rtl frames, or is it the failure of a horizontal scrollbar to appear when the webpage is too wide?

The bug is with the vertical scrollbar.

The my words about the horizontal scrollbar was just wishful thinking. Perhaps it could reach someone who sees the advantages of it and has some influence with the W3C. It was just lateral thinking.

The main issue is that, that the decision of where the frame-scrollbar should be, must be left to the Web-designer.
I am not interested in the actual component. Just wanted to point out, that the bug effects normal western-european pages, not just the Hebrew and Arabic ones.
Perhaps a simple name-change would help: include "rtl" in the name of the component. It has a psychological effect. The current name suggests, that it is an issue for the the semitic languages, thus sometimes someone just says: They do not interest us, there are not enough users, so why should we bother.
But the placement of frame-related scrollbars is a web-design issue, making many pages more usable, this should be reflected in the name of the component, and in the attitude of the developers.
I think this is in fact a dupe of bug 265276.
#8: I think you are right, but there is a difference: with that bug it says, it is fixed. But it is not, at least not for the frames.
I am also trying to avoid confusion between the frame's and the broswer's Scrollbar.
If both are on the right hand side, and the contents of the page are wider then the screen, so that the Frame-scrollbar is not visible, it is not obvious, thet there are two (or more) scrollbars.
Bug 265276 is fixed on trunk builds, not in the 1.8 branch. 

On a trunk build the scrollbar in site-help at http://www.rakovszky.info appears on the left of the frame when the pref layout.scrollbar.side is set to 1.

*** This bug has been marked as a duplicate of 265276 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → DUPLICATE
Please explain:
What is a Trunk-build?
How can I verify that it is working.
Is it included in FF-2 RC3?
If not, will it be included in the next RC? If not, it is not resolved
It does not work in FF-2 RC3
If I cannot verify that it works for my page, I will have to reopen it.
(Suggestions for small modifications to the source-code are acceptable, as long as they do not affect the other browsers.)
(In reply to comment #12)
> It does not work in FF-2 RC3
> If I cannot verify that it works for my page, I will have to reopen it.
> (Suggestions for small modifications to the source-code are acceptable, as long
> as they do not affect the other browsers.)
> 

Trunk builds are those on the bleeding edge development. The current trunk will branch off to become Firefox 3 sometime in the future.

Reopening is not really an option here, if it is a dupe as you say then it must stay as a dupe.

I suspect you are also misunderstanding what resolved means in this bug system. It does not refer to whether the issue is solved in a current release of Firefox, it means that the issue is solved in trunk builds and so will appear in a future release of Firefox.

For me "Resolved" means that it is going to be working correctly at the next corrected version, or at least within the near future.
You should invent a new category for bugs where the problem has been verified and the solution is known, but will not be corrected soon.
Say: 
Resolved (FF-3): correction not before FF-3
Resolved (FF-2): Corrected in next release of FF-2
Resolved (FF-1): Corrected immediatelly in FF-1 and subsequent versions)
This addition would mean a verifiable commitment to correct the bug.

Then one knows the real status.
I have seen bug-reports called "Resolved", where the correction was never implemented.

I just do not understand, why do you not make an effort to correct all known bugs, if not in the current version of FF-1 or 2, but in 2.0.1, etc.
Why do you have to wait another year or so?
That is a sure way to fall behind the other browsers.

Buggy incompatibilities are reported in all browsers, so when others repair known bugs quickly, but they remain in FireFox for years uncorrected, users will simply switch to ther browsers.
We use keywords like fixed1.8.1 to indicate that bugs are fixed in upcoming releases. General discussion of release management would be more appropriate in a newsgroup than a bug report. 
#14: I have no time for any news-group. The issue is the fate of this bug-report and transparency for the reporter. I do not care, about your conventions, the only thing that is important for me, is to know roughly, when will be a properly working version released.
Even a term like: "this cub will be born in FF-3" would be quite clear Fixed-3 as addition to Resolved would make all things clear. But when some bugs are there even 7 years after being reported, you mast accept, that a Status "resolved" is not satisfactory. 
(In reply to comment #16)
> #14: I have no time for any news-group. The issue is the fate of this
> bug-report and transparency for the reporter. I do not care, about your
> conventions, the only thing that is important for me, is to know roughly, when
> will be a properly working version released.
> Even a term like: "this cub will be born in FF-3" would be quite clear Fixed-3
> as addition to Resolved would make all things clear. But when some bugs are
> there even 7 years after being reported, you mast accept, that a Status
> "resolved" is not satisfactory. 
> 

'resolved' means 'resolved as a duplicate'. Nobody every said that it means 'resolved as fixed'. It could easily be that the other bug (bug 265276) was still not ready, or it could even be closed as invalid or whatever. The status of *this* bug is still resolved.

Note: the fix is in the Gecko library, which is the base for Firefox, but also for Seamonkey, Camino and Minimo. We can't just have a specific status for when it will be fixed in Firefox, then we would need it for the other browsers as well.
In this case: that target milestone is mozilla 1.9 alpha (Gecko 1.9), and it doesn't carry a fixed.1.8.1 keywords, so it's not backported to the 1.8.1 branch. Firefox 2.0 uses Gecko 1.8.1, so it doesn't have the fix. Firefox 3.0 will be based on Gecko 1.9 (as planning currently says), so it will have the fix.

This is a clear and intelligible statement, that I can accept.

If someone said that at the beginning, a lot of annoyabce could have been saved.

Perhaps new bug-reporters should get an automatic email explaining some things, which are clear to your community, but not to outsiders.

I expect FF-3 will be much the same as FF-2, but with the new Gecko-engine.

Now the only thing I can do is to sit back and keep my fingers crossed that Gecko 1.9 FF-3 comes rather sooner than later.

I have just one further request: please notify me, when it is so far that I can test it.
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: layout.bidi → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.