@kas1e

So for your information, this newer script handles many more youtube videos since i added signature decryption. The problem is probably that OWB 1.23 didn't support "for...of" js construction which is quite recent (1.24 is the current test version, and it supports all this fine).
And by the way, the issue is clearly shown in inspector or in message window.

Anyway, I modified it so that it doesn't require it, so you can download the new 0.95 version. It does as much as youtube_centre, compatibility-wise, but it's way smaller and lighter.

@kas1e & Samo79

Please don't make wrong assumptions... I test what i release.

0.94 works just fine on MorphOS (and it fixes that layout issue introduced recently by YouTube).

As for the size, it's perfectly normal it's smaller. I got rid of jquery usage, which reduces considerably the script size.

@kas1e

With the p96 api, i know it's already able to define a specific area for the video layer and you can add anything you want around, it's not the problem here.

The real question is if the limited p96api is able to ATTACH a video layer to an EXISTING window.

@kas1e

Youtube probably runs lots of js scripts on main page for some reason. That said, as soon as you go to a particular video, the idle state goes back to 0% usage. That's just the main youtube page being so demanding in idle state.

@samo

Just bind the html to open url (or 'URL' in OS4?) already. If you really want to bind it to odyssey directly, then you'll have to do it so that it calls it as file:///yourfile.

@utri007

You can use Youtube's HTML5 player, but since there are still many videos not available as HTML5, you'd better rely on youtube.js / youtube_fullscreen_fix.js ( youtube_center userscript available at userscripts.org is also nice). All videos will play then. Just read the documentation at youtube section, it's explained in details.

Besides, the video playback is faster when using builtin HTML5 player rather than Youtube's HTML5 player (less rescaling and js involved).

About the HTML5 player implementation, it's not a separate executable. It's a player i wrote from scratch, embedded in Odyssey, relying on ffmpeg libraries to decode the video/audio files.

And anyway, the bottleneck is not the player itself, but the slowness of the cairo backend (displaying 25 frames per second using cairo image surface is rather suboptimal, which is why i implemented a direct overlay mode, which is unfortunately not available in the OS4 version yet, due to the limited p96pip API).

@kas1e

This multiple threads part is implemented and enabled in morphos, just so that webkit synchronization and compilation are made easier, but it's actually not used at all in practice (this code is used by external jsc clients, and possibly by webkit2, but not webkit itself). It's also totally unrelated to javascript workers, for instance.

Regarding the code itself, while Forbid() might be enough, I definitely wouldn't recommend Suspend/RestartTask.

@xenic

Of course using malloc() is a non issue, if the underlying clib is properly done. In MorphOS, it internally uses a mempool and all the allocated memory is given back at exit.

On the other hand, i really wouldn't use directly AllocVec*/AllocMem* in WebKit, and especially JSCore, because it tends to leak a lot (due to remaining live js references/objects in allocated blocks), and as a consequence, the leaks wouldn't be recovered at all after program exit.

At least, if you really don't want to use malloc(), at least keep track of your allocation, or better, use a mempool.

So, OS4 is incompatible with AmigaOS 3.x?
Many programs use tc_UserData. tc_UserData is meant to be *used* by the programs, not by the operating system (hence the name).

@kas1e

Probably your threading backend has an issue with the startup/end message handling. It might only appear now in 1,23 because more threads are involved (garbage collector thread, localstorage thread and, all the mediaplayer threads and so on...).

@ChrisH

Quote:

No, he wasn't... Marcik brought WebKit to an amiga-like platform years before that, and with a usable GUI, too. And it was much more work at that time, because there weren't SDL or Cairo backends that made WebKit so easy to port.

@kas1e

I won't even comment on Joerg's nonsense about malware and naming. You can rename if you want, but you're on your own if you have issues later with software depending on that, because i'll keep OWB on my side.

And about your actual issue, it's rather suspicious send() fails if connect() really succeeded. All this happens in main thread context, so unless the socket was already closed before or that the socket descriptor value got changed, i fail to see how it could happen. Maybe your CURL port has an impact on that somehow, though, to be checked.

Anyway, you can askJoerg now, i'm sure he will help. :) But just for your information, since June 2010 (i.e the WebKit revision OWB Reaction is based on), WebKit got more than 100000 revisions. There were *many* API changes in backends as well.

@Raziel

In URL string you can invoke another search engine by using its shortcut (configurable in search engine settings). So for instance, "y blah" to search on youtube or "a blah" to search on aminet.

@kas1e

It doesn't happen when js is disabled because websockets are js-driven, of course. But your issue is still not about "javascript", but about the websockets backend.

Regarding your thread stuff, it won't have any effect. It all happens in main thread context (it would be different if js workers/shared workers were enabled, but they aren't, for a good reason).

@tlosm

It's not related to memory usage at all.

@kas1e

Both point to websockets, at least. and It's totally unrelated to js in general, but to the websocket network backend, so basically BCSocketStreamHandleCurl.cpp.

In your case, it seems the socketstream client leads to deleting the socketstream handle itself, but then calls the socketstream again, hence this 0xCCCCCCCC address.

It also happened in MorphOS in some versions before, and the fix was basically to protect the handle with a RefPtr in the right place so that the handle doesn't get deleted. That said, since it crashes on OS4 and not MorphOS, i don't get why it happens, but what's sure is you should debug that piece of code (and the generic WebCore/Modules/websockets code) if you intend to fix it.

@kas1e

in the MorphOS version, you would just have to use mplayer file without even specifying the video output driver. When overlay is available, it's used, else it falls back on cgx_wpa (or cgx_vmem). And it certainly doesn't crash here if overlay (or any video output driver) is not available. It falls back to the following one in the list, and if none can be opened, it plays sound only, or quits properly.

So if it crashes for you, it's likely the original p96pip vo driver is buggy and doesn't check properly avaibility in preinit function.

@samo79

I implemented this paste&go url contextmenu item, but it appeared in a submenu instead of below the other entries, and it didn't look good, that's why i disabled it, since i didn't find how to put it at the same level as the other entries. And i had much more interesting things to do in the browser in the meanwhile.

And by the way, if you find it's not friendly from edit menu, you can just press amiga+g, it's even faster that way.

@djrikki

Err, while it might happen in URL address if you didn't remap mui shortcuts for string class, it definitely shouldn't happen in webview text fields. Pgup/down/home/end are handled entirely differently inside the webview, and this can't happen (on MorphOS at least).

@samo79

I didn't change anything, and it's not directly related to Odyssey itself, it's the default behaviour of MUI string class when pressing home/end/pgup/pgdn keys. Maybe default shortcuts changed on MUI OS4? Anyway, these events can still be caught to do something else, it's quite trivial to do.

As for "Paste to URL" contextmenu item, it was never enabled in the MorphOS build, AFAIR.

@kas1e

amiga|ctrl + [shift] + z works in any text field, text area (such as the one i currently use for this post).

style shortcuts work in html5 rich text editors, such as http://xing.github.io/wysihtml5/

@samo79

Aehh, it's more than that. With odyssey you have two autoscroll modes...


With a single mmb click you have autoscroll in the webview, as long as mmb is pressed.

With double mmb click you have autoscroll in the webview, without the need to keep the button pressed.

@kas1e

The video playback in window mode is mainly dependant on Cairo performance itself. Cairo is the bottleneck, the gfx driver is less important there, unless it's very very slow, of course. :)

Regarding Overlay support, I already check if overlay is available of course. You could always add a nag requester, but it's really not needed at all (it even displays a message in messages windows about not being able to create a video layer, anyway).

With P96, it seems you can't attach a vlayer on an existing window, so it will be hard to make it work like it does on MorphOS. Of course it would be easy to create a fullscreen instead, but you have to keep in mind it has to deal properly with external events (i.e switching back to odyssey window, closing tab, scrolling in the related page and so on...). As you can see, a real fullscreen mode raises several usability issues. So better be VERY careful about that.

And regarding the existing fullscreen mode, the status can already be hidden with middle mouse button. As for tabs, it could probably be done with a bit more work, but it's not really a priority now.