[Patch] Browser scrollbars, iOS-like style

[isagar2004]

12/11/11: I made some performance and cosmetic improvements to the patch. DO NOT update through Preware. For some reason, the patch build server broke something in the patch and it doesn't patch all the needed files. I already contacted Rod about it, hope it'll be fixed soon.
EDIT: Rod didn't answer, so I checked it myself. Apparently, the patch build server changed the patch code for some reason and made it useless. I've resubmitted the patch and I hope that everything would work after the approval. The updated version in Preware works fine now. Get it there.

Update: Approved and now in Preware. Get it there.

Update: Border added to make the indicators more visible on a black background (BTW, if anyone knows why it is taking so long to get the patch approved in Preware, please let me know).

Update: Fixed bug that caused the horizontal scrollbar to show incorrect position.

As you probably know, one of the most annoying issues with the beautiful webOS browser is the lack of scrollbars. There are two browser scrollbars patches in Preware (TIWizard's and veerar's). However, I found them both not very convenient and not really useful, so I decided to develop my own patch that adds scrollbars that looks like iOS' scrollbars.

Here are some screenshots. As you can see, there are wide and half transparent "indicators" which helps figuring out quickly where you are in the page.

It works perfectly in both portrait and landscape mode.
I've already submitted this patch to Preware, so expect it to appear in the patches feed in the coming days.

It's fully compatible with 2.1, 2.2 and 2.2.3. I didn't check earlier versions.

[ElectronicMan]

Any possibility for a Touchpad version? Nice work!

[johnsonx42]

nice. I didn't know I wanted scrollbars until I saw them in your screenshots... now I think maybe I do want them!

[isagar2004]

Originally Posted by ElectronicMan

Any possibility for a Touchpad version? Nice work!

There's always a possibility. However, since I don't own a TouchPad and because I'm not familiar with enyo, it'll take time.

Originally Posted by johnsonx42

nice. I didn't know I wanted scrollbars until I saw them in your screenshots... now I think maybe I do want them!

You definitely need them

[ahsirg]

isagar2004, maybe you could take a look and make a global patch for all Mojo.Scroller controls so we have these things everywhere
Great work so far!

[isagar2004]

Originally Posted by ahsirg

isagar2004, maybe you could take a look and make a global patch for all Mojo.Scroller controls so we have these things everywhere
Great work so far!

Good idea!
It's not so easy as it might sound, but I'll take a look and see what I can do.

[Mutoidi]

Brilliant.. YES!
TP version would also transform the experience of swiping endlessly to the bottom of a 200 post forum etc?

Go fot it!

[isagar2004]

Originally Posted by ahsirg

isagar2004, maybe you could take a look and make a global patch for all Mojo.Scroller controls so we have these things everywhere
Great work so far!

Originally Posted by Mutoidi

Brilliant.. YES!
TP version would also transform the experience of swiping endlessly to the bottom of a 200 post forum etc?

Go fot it!

Patching the TouchPad's browser application turned out to be complicated than I thought and as I see it now, the patching will require almost rewrite of the Browser.js file and some other files. On the other hand, it looks like patching the Enyo framework is going to be even easier than the patching I planned for Mojo. I don't really have time these days, so I'll start working on Enyo in the weekend, as soon as I'll be sure that there is no way to patch the Mojo.Scroller.

[eblade]

A potential problem in patching Enyo, is that many apps use the VirtualList control, which basically only keeps in existence at any given time a handful of entries other than what is visible, so it might be really hard to determine where the end of something is.

[d12r]

Originally Posted by isagar2004

Patching the TouchPad's browser application turned out to be complicated than I thought and as I see it now, the patching will require almost rewrite of the Browser.js file and some other files.

A complete rewrite is certainly not necessary. Have a look at Nightburn's excellent "Browser Gestures" patch which implements overlay items in the browser.

On the other hand, it looks like patching the Enyo framework is going to be even easier than the patching I planned for Mojo.

So you found a way to extract the current scroll position from a browser object? Because even if it is obviously supposed to work like its Mojo counterpart, the (undocumented) scrollTo callback in enyo.BasicWebView is useless, it is not supplied with actual x/y data by the browser object.

[Nightburn]

Graphically this type of patch is certainly possible on a Touchpad. However, that's where it ends, we still have no way to get any information from enyo about the current scroll position. It's my opinion, when it comes to the web browser on the touchpad, a patch that does anything at all "scrolling related" is NOT HAPPENING UNLESS HP OPENS UP THE COMPILED BITS

Myself and others have already spent many hours trying different techniques to modify scrolling within the browser. The compiled part, "the browser adapter" is the road block. There is no way to get any information from the browser adapter regarding the current scroll position and also no enyo method to tell the browser window where to scroll to. Mojo has that stuff, enyo does not.

Now if anyone manages to figure out some magic, please PM me. I'm highly interested in adding various scrolling options to my patch "Custom Browser Gestures".

[eblade]

I'd think it would be more valuable to spend one's time poking at the javascript stuff we can see (Enyo) rather than the compiled binaries, that it takes very special skills to be able to patch with any effectiveness whatsoever.

[isagar2004]

Originally Posted by d12r

A complete rewrite is certainly not necessary. Have a look at Nightburn's excellent "Browser Gestures" patch which implements overlay items in the browser.


So you found a way to extract the current scroll position from a browser object? Because even if it is obviously supposed to work like its Mojo counterpart, the (undocumented) scrollTo callback in enyo.BasicWebView is useless, it is not supplied with actual x/y data by the browser object.

Originally Posted by Nightburn

Graphically this type of patch is certainly possible on a Touchpad. However, that's where it ends, we still have no way to get any information from enyo about the current scroll position. It's my opinion, when it comes to the web browser on the touchpad, a patch that does anything at all "scrolling related" is NOT HAPPENING UNLESS HP OPENS UP THE COMPILED BITS

Myself and others have already spent many hours trying different techniques to modify scrolling within the browser. The compiled part, "the browser adapter" is the road block. There is no way to get any information from the browser adapter regarding the current scroll position and also no enyo method to tell the browser window where to scroll to. Mojo has that stuff, enyo does not.

Now if anyone manages to figure out some magic, please PM me. I'm highly interested in adding various scrolling options to my patch "Custom Browser Gestures".

There are scrollX scrollY functions in the Browser Adapter. They suppose to return the X and Y values of the current position (I haven't tried it yet).

[d12r]

Hah. HAH, I say.

I managed to extort the scroll position from the browser. Now to retrieve the page dimensions ...

[isagar2004]

Originally Posted by d12r

Hah. HAH, I say.

I managed to extort the scroll position from the browser. Now to retrieve the page dimensions ...

This is good news.
Can you share more details? How exactly did you manage to get the scroll position?

[d12r]

Originally Posted by isagar2004

This is good news.
Can you share more details? How exactly did you manage to get the scroll position?

By finally properly understanding enyo event propagation. It's actually stupidly simple, and my face is pretty red for not getting it before. I was considerably thrown off by enyo adding "inSender", pointing to the control that fired the event, as the first variable. This made me believe that the callback doesn't work when it actually does. Don't laugh, I'm just starting out with this.

As some of you might already have discovered, the WebView control has an undocumented event named "onScrolledTo"*. That event is fired with the x and y scroll positions whenever the browser is scrolled. If you, in browser.js, add an event to the Webview control, e.g.:

(...)
		{name: "view", kind: "WebView", flex: 1, height: "100%",
			onScrolledTo: "scrolledTo",
			onMousehold: "openContextMenu",
			onPageTitleChanged: "pageTitleChanged",
(...)

and catch that with a function, e.g.

scrolledTo : function (inSender, inX, inY) {
(...)
}

you will get proper x/y coordinates. Interestingly, the coordinates are factoring in the page zoom, and with negative values, so it seems like these are "where is WebOS putting the virtual page within the viewport" coordinates.

This leaves two other tasks, a simple and a hard one, to build a proper scrollbar (at least as an indicator): a) retrieving the current viewport size (i.e., the size of the visible area on screen). This should be rather easy with an enyo.calcModalControlBounds() call. I haven't tried this yet tho. b) is a bit harder: retrieving the dimensions of the current page size (factoring in the page zoom)

FWIW, I tried retrofitting SimpleWebView.js and WebView.js with the pageDimensionsChanged callback handler and feed it into an event, but it doesn't even seem to fire. Maybe I'm barking up the wrong tree here and there's a simple way to get the page dimensions.

Cheers
Freddy

P.S. / Edit: To have a look at what's going on, you can abuse the address bar as an output device:

scrolledTo : function (inSender, inX, inY) {
  this.$.addressbar.setUrl("scroll position: " + inX + "/" + inY);
}

P.P.S.: *) There's another event named "onScrollTo", not to be confused with "onScrolledTo". "onScrollTo" fires when the browser decides it needs to scroll somewhere on the page, most prominently when the current URL has a fragment identifier, and is useless to this discussion.

[d12r]

To quote myself:

Originally Posted by d12r

a) retrieving the current viewport size (i.e., the size of the visible area on screen). This should be rather easy with an enyo.calcModalControlBounds() call.

Turns out I'm right. enyo.calcModalControlBounds(control) will return an object with width and height properties. When used in the callback handler, it's even easier because the control is conveniently already returned as inSender variable. So if you extend our function to

scrolledTo : function (inSender, inX, inY) {
  var v = enyo.calcModalControlBounds(inSender);
}

it has scroll position in inX and inY, and the viewport height in v.width and v.height.

Now we're left with retrieving the current page dimensions and we can have ourselves a scroll indicator.

[isagar2004]

Originally Posted by d12r

To quote myself:


Turns out I'm right. enyo.calcModalControlBounds(control) will return an object with width and height properties. When used in the callback handler, it's even easier because the control is conveniently already returned as inSender variable. So if you extend our function to

scrolledTo : function (inSender, inX, inY) {
  var v = enyo.calcModalControlBounds(inSender);
}

it has scroll position in inX and inY, and the viewport height in v.width and v.height.

Now we're left with retrieving the current page dimensions and we can have ourselves a scroll indicator.

Not exactly. We still need scrollStart event or something like that to know when to show the indicator. I think that scrolledTo acts more like scrollEnd, isn't it?
Also, did you try using enyo.fetchControlSize(inSender) to get the page dimensions?

[d12r]

Originally Posted by isagar2004

Not exactly. We still need scrollStart event or something like that to know when to show the indicator. I think that scrolledTo acts more like scrollEnd, isn't it?

No, it's what in a browser context would be an "onscroll" event. The event is fired whenever the scroll position changes, and constantly throughout the scrolling process (I guess depending on the screen update rate). In a combination with a timeout it should do the trick just fine.

Also, did you try using enyo.fetchControlSize(inSender) to get the page dimensions?

Yes, as the function name suggests, it retrieves the size of the control, not the size of the (virtual) page. Also, practically the same result with clientWidth and offsetWidth on the control's node property.

[isagar2004]

Not sure what is that, but try using Tellurium.getDimensions(inSender), it returns width and height values that are not calculated through clientWidth or offsetWidth. It might be it, or might be just the same thing.