[Patch] Browser scrollbars, iOS-like style

[d12r]

Originally Posted by 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.

I won't bother. If you look into the source of tellurium/dom.js, that function it is nothing but a wrapper that returns offsetWidth and offsetHeight.

Furthermore, it appears that the pageDimensions callback in BasicWebView.js has been disconnected as early as in enyo-build.js. No wonder it won't fire. Can we actually modify enyo-build.js?

[isagar2004]

Originally Posted by d12r

I won't bother. If you look into the source of tellurium/dom.js, that function it is nothing but a wrapper that returns offsetWidth and offsetHeight.

Furthermore, it appears that the pageDimensions callback in BasicWebView.js has been disconnected as early as in enyo-build.js. No wonder it won't fire. Can we actually modify enyo-build.js?

We can practically modify every file in the system (including framework core files).
I'm struggling here with patching the right mojo scroller functions, hope to succeed soon.

[knownboyofno]

Originally Posted by d12r

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.

That was as far as I got but I was trying to figure out how to get the total page size.

[geniusjack45]

nice work~!Love it !

[d12r]

Furthermore, it appears that the pageDimensions callback in BasicWebView.js has been disconnected as early as in enyo-build.js.

... bah, and of course, enyo-build.js is just a whitespace-compressed collection of the single source files. Another dead end towards finding page dimensions. It seems like the only callback that would transmit page dimensions to the control scripts is not firing, at all.

[eblade]

where abouts are you looking, if i might ask?
I've poked around through BasicWebView to do some pretty weird and miraculous stuff..

[d12r]

Originally Posted by eblade

where abouts are you looking, if i might ask?
I've poked around through BasicWebView to do some pretty weird and miraculous stuff..

Did you stumble upon something that would help? BasicWebView is really the only place to look since it's the interface to the browser. I agree, it's a very interesting control with lots of obviously unfinished or untapped parts. But nothing I see in there would help in the remaining task. I'd gladly stand corrected tho.

[isagar2004]

The patch is now in Preware. Get it there.

[ShiftyAxel]

I don't suppose you guys have run across anything pointing to FPS values during your foray into Enyo? The Pre3 and Touchpad are fully capable of pushing framerates of 60-100 most of the time (as proven by my Mojo FPS Booster patch), but I can't for the life of me find anything that sets Enyo's equivalent to Mojo's targetFPS value.

Also, when running Mojo with a targetFPS of 100, your scrollbars patch seems to significantly lower the FPS, I imagine because of the calling/rendering or something. Any chance you could take a look into it?

Update: It seems to lower scrolling performance in all mojo apps for some reason...

[isagar2004]

Originally Posted by ShiftyAxel

I don't suppose you guys have run across anything pointing to FPS values during your foray into Enyo? The Pre3 and Touchpad are fully capable of pushing framerates of 60-100 most of the time (as proven by my Mojo FPS Booster patch), but I can't for the life of me find anything that sets Enyo's equivalent to Mojo's targetFPS value.

Also, when running Mojo with a targetFPS of 100, your scrollbars patch seems to significantly lower the FPS, I imagine because of the calling/rendering or something. Any chance you could take a look into it?

Update: It seems to lower scrolling performance in all mojo apps for some reason...

I don't remember seeing anything related to FPS rates in the Enyo code, but this is probably because I didn't look for it.
My patch makes the browser re-render the scrollbar element on any change in the scroller position. This, of course, might affect the performance and the FPS.

-- Sent from my Palm Pre3 using Forums

[The Bard]

When I go to advance search ie: at precentral using TP, I have problem navigate 'search in forum' options. Can you update this patch to add scrollbar so I can navigate it?, keyboard can't be opened so arrow key can't be used.

[knownboyofno]

Originally Posted by The Bard

When I go to advance search ie: at precentral using TP, I have problem navigate 'search in forum' options. Can you update this patch to add scrollbar so I can navigate it?, keyboard can't be opened so arrow key can't be used.

Offtopic: Check out this http://forums.precentral.net/hp-touc...n-browser.html it lets you bring up the keyboard anytime.

[locbuondoi]

how about 3.0??

[hkowalczyk]

Originally Posted by d12r

(...)
		{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.

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

Did you do this on 3.0.0 or 3.0.2? I tried on 3.0.4 but it looks like onscrolledto is broken in enyo-build.js

scrolledTo: function(a, b) {
this.doScrolledTo(a, b);
},

it should be

scrolledTo: function(a, b,c) {
this.doScrolledTo(a, b,c);
},

the negative values seem to just be the right values with a negative sign. there seems to be an easier method... but I don't know enough html/js to pull it off quite yet. go to

Detemining browser dimensions and document scroll offsets

and about the middle of the page click on the example "click here" if you look at what on scrolledto returns and what this returns you'll see they are the same magnitude but different signs until the page is zoomed in, then the values in onscrolledto are scaled, but these remain unscaled, so it should be easy to use them to scroll back to the right position.

I can't get them to return anything other than 0,0 though when I cut and paste the code into the browser.js scrolledto function.

-Henri

[d12r]

Originally Posted by hkowalczyk

Did you do this on 3.0.0 or 3.0.2? I tried on 3.0.4 but it looks like onscrolledto is broken in enyo-build.js

It works on 3.0.4. Also, enyo-build.js is not a source file intended for patching, it is a compilation of all source files to "build" the system on boot and therefore only reflects the changes in other source files. I didn't have to change any Enyo core scripts to make it work, by the way.

there seems to be an easier method... but I don't know enough html/js to pull it off quite yet. go to

Detemining browser dimensions and document scroll offsets

That's web page JavaScript, executed within the context of the web page. You can't just copy & paste web page JavaScript into an Enyo application and expect it to magically work.


All that being said, I don't think it's worth following that particular topic any further. The 3.0.5 update will bring scrollbars to the browser. (Personally, and get your eggs ready, I have moved on to Android. As much as I like WebOS as an OS, the applications built on it are unbearably beta and I don't expect that to improve anytime soon.)

[hkowalczyk]

Originally Posted by d12r

It works on 3.0.4. Also, enyo-build.js is not a source file intended for patching, it is a compilation of all source files to "build" the system on boot and therefore only reflects the changes in other source files. I didn't have to change any Enyo core scripts to make it work, by the way.

That's web page JavaScript, executed within the context of the web page. You can't just copy & paste web page JavaScript into an Enyo application and expect it to magically work.


All that being said, I don't think it's worth following that particular topic any further. The 3.0.5 update will bring scrollbars to the browser. (Personally, and get your eggs ready, I have moved on to Android. As much as I like WebOS as an OS, the applications built on it are unbearably beta and I don't expect that to improve anytime soon.)

Odd... it worked fine when I changed it but not until then, but I did it on the emulator not on the touchpad.

No magic expected, at the time I hadn't realized that the webview was actually sandboxed via the browserserver so expected the document.body to point to the web page not the local filesystem.

Now that it has the scroller built in it might be easier to keep the page location when opening up new page, otherwise the scrollto hook would be nice to get.

[bethel95]

Now that 3.0.5 has been released to the TP, will the new browser scroll bar code make it possible/easier to create a patch for a functional (as opposed to view-only) scroll bar?

[eblade]

Probably no different, it is quite likely built into the webview native code, since it works in all webviews

-- Sent from my TouchPad using Communities

[isagar2004]

Probably no different, it is quite likely built into the webview native code, since it works in all webviews

-- Sent from my TouchPad using Communities

Exactly. It's hardcoded into the BrowserAdapter.so library.