These work with Opera, Firefox and WinIE. See:
It could be something wrong with the scripts, or it could be our bug. Someone needs to reduce it.
Created attachment 6398 [details]
Testcase reduction (partly)
(In reply to comment #0)
> These work with Opera, Firefox and WinIE. See:
> It could be something wrong with the scripts, or it could be our bug. Someone needs to reduce it.
Hi, I am the author of the script. From until version 1.1.0, I started doing a Safari block by default so Safari users can browse the contents without problems. For easy testing, I am leaving a no-block version at this address:
I don't have a Mac to do any further reduction. I'd appreciate any feedback.
Ok, this first bug is fixed.
And that was the whole issue. The native bars were just obscuring the non-native ones. It's all good now.
Thanks for the information. I will remove the Safari block with the next update.
Actually you could work around the bug now I suspect if you just don't do the auto->hidden swap. In Safari only just start off with the overflow sections set to hidden.
Latest Safari release and latest WebKit before this fix already show different behaviour using your scrolls. Especially, the top right box can be scrolled with the latter, since the scroll bar isn't completetly obscured by the native scroll bar. This might imply that there were another, now fixed, bug between latest release and latest nightly, that your scrolls needed fixed.
Just so you know, even if it's fixed in WebKit doesn't mean Safari immediately gets the fix. Safari updates usually come with OS X 10.x.x updates, which are a couple months between. Also, I think there is no knowing if this very bug fix gets into such an update, well maybe unless you are Apple. And then there is the state of Safari on 10.3, of which I know little (don't know if only security fixes go there, or other fixes also).
All in all, I think that if you want as many as possible to be able to interact with your pages, you should wait until a released version of Safari supports the custom scroll bars, and then sniff for that version number, blocking earlier versions. Unless you find a workaround, of course.
I finally got around detecting newer Safari's (>2.0.4), and implemented it on
as beta. I thought of bug detection but that would elongate the code a lot, so I simply went for HTMLElement and HTMLElement.prototype detection on top of the simple user-agent Safari detect, which allowed me to run fleXcroll on new webkits, while successfully blocking old Safari's with the fewest line of code. I'd appreciate if you could do some testing, I am testing using a VNC server and I could only get thus far.
Thanks David, I had already seen that and would resort to that method had HTMLElement.prototype not been implemented on new webkits. I had to go for the simpler approach of browser capability, with the fewest size overhead. I think many script author's would do the same instead of messing with version numbers. I am hoping new bugs are not introduced of course. Safari 3.0 will be what matters.