but it's for sure availible under the "Edit" menu and it works from there
I can't check now, but maybe it just was some additional setting to contextmenu done myself :) I mean, you can construct main context menu as you wish, and i assume put that functionality where you need by mime types.
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.
I can't check now, but maybe it just was some additional setting to contextmenu done myself :) I mean, you can construct main context menu as you wish, and i assume put that functionality where you need by mime types.
I don't think it will work because it's not the same user configurable menu, that copy and paste functionalities (for the address area) seems internal so to change them i presume you should modify the current source code
@Fab
Understand, well no a big problem but i hope someday you will implement it at 100%, for now of course i'm using the amiga+g combo
@Samo Thore deal already with that enhancement and i already have beta in tests: now "alt" qualifier added to do marking. I.e. all previous combos works as before, just if you press them with alt, you mark data. If you press alt + cursor keys, it mark single characters, if you press alt+home or alt+end, it mark text from cursor position till end, or till begining of string, you also can mark by words : originaly with ctrl+cursor keys you can jump over words, now, the same combo but just with added alt (i.e. alt+ctrl+cursor keys) will mark words. I.e. just check current muiprefs/keyboard, and imagine that for almost everything you can add "alt" now, to make the same, but for marking. Also was added some more handling for input to avoid typing of those characters when they in no use. In other words, its cool now. Will be good if morphos devs will add to their mui something like this, can help for usability for sure.
Yes i'm following the daily progress from the MUIdev site so i read that already! Great news for sure, most of the problems related to the OWB usability are now solved and just the double buffering still in progress
It only mean that i use it everyday, but didn't releaze because there is that problem about which i told (and which present on all versions, and in 1.9 and in 1.16): some sites crashes on os4 version while the same sites but on morphos version didn't. And so, i think about how to make it all in one new topic, with links, different crashlogs, and so everyone can suggest what going on. I curently trying myself understand why it happens, and have only ideas that it can be because of timing as Joerg say me before (but i tried his timing code from his owb, and it didn't help, or i just use it wrong) , or, which is also possible, some thread runs outside of main process somewhere, or, for compiler i use there is some bug which make something bad, or .. or whatever else :)
So its kind of same problems, and i am sure it crashes for ppls offten on heavy pages because of exactly that. But webcore code the same of course and i change nothing in terms of JS for example or so. If only there is somewhere something which should be done somehow differently for os4, but what and where .. Maybe some different compilation flags.. I do not know currently. Maybe "fastmalloc" can be disabled, maybe something else. Dunno. Maybe there need to open somewhere new instances of ISocket, to avoid that problem (as seens from crashlog its related to handle of sockets). Or maybe all about timing. Really dunno. Maybe os4 catch something which morphos didn't and bug present just in webcore itself.
As both crashes point out on 0xCCCCCCC (as i on debug + munge), it mean "you have tried to free a Node a second time". So maybe some wrong free() somewhere, or dunno what. Together with DEADBEEF in one of registers its cleary point out on problems with memory, but it all can be anything.
@All Anyone skilled and brave enough to help with and dig in into code ?
Edited by kas1e on 2014/2/18 5:52:37 Edited by kas1e on 2014/2/18 5:53:20 Edited by kas1e on 2014/2/18 5:54:31 Edited by kas1e on 2014/2/18 6:05:21
@tlosm You can try it yourself on 1.16 (on bombermine.com for example). Both sites didn't allow you going futher than just main pages without JS: so i can't say if it JS related or not. And even if, it still didn't mean that its related to JS itself, as it can be just with enabled JS a lot of data handles, and bug come out.
Through as i see Kicko deal with all his problematic sites by disabling JS, but still it can be not JS itself, but anything else. And crashlogs point out on timing/sockets handling, not on something in JS.
umm do you check with snoopy what library or mod did this issue... can be something related using of ram? check on mem/vmem meter if this sites are using much ram and make Odyssey crash, some times jquery make issue with system with low memory.
i see Odyssey crash only on Efika when ram finish because webkit is huge mem eater
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.
Dunno at all what is all about, only see that its m_curlHandle which is 0x0000000 in the SocketStreamHandle::platformClose. Maybe its somehow related to way how websocket's threads created/deleted ? Because for example for os4 port (and before and now) we had to do one more change related to threads to make aos4 version works : in BAL/Types/WTf/BCThreadingWTF.cpp:
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).
It doesn't happen when js is disabled because websockets are js-driven, of course
Is it necessary to have websockets enabled at all ? I mean, did it give any benefits except html5test.com ? If i will just disable them will everything works as expected just without websockets ?
What is interesting, those websockets seems involved rarely, and even if they calls ones time, no crash happens. For example when i go to html5test.com i have:
And its really so rare i see that debug, can visit about 10 heavy sites with JS, and those sites don't use websockets, and no calls from all those SocketStreamHandle (no surpise that not all sites crashes, so i even didn't notice it at all before).
And exactly same crash if i trying to use "secure websocekts (tls)", of course.
I think that maybe curl should be build somehow different, but then tried with pure curl binary done from my libcurl.a which i use with odyssey, and seems websockets works, etc:
@Fab Omiga !! I fix that crap ! It was indeed didOpenCallback and all what i do its the same as you do for other fucntions, right at top adding protect , i.e.:
// This starts polling for notification.
m_pollTimer.startRepeating(pollInterval);
}
So now on websocket.org i pass both tests for connect (plain and secure ones), as well as bombermine.com works fine now and didn't crashes, as well as mail.yandex.ru works too ! Omiga1200 !
Btw, that bombermine.com seems so far only one site i found which heavy use websockets, i mean really heavy (While with mail.yandex.ru it was just 2 instances). bombermine.com anyway didn't works as it should by default: after i choice "play as guest" it didn't load everything (same on morphos as well, but it works on my win32's chrome). But when i spoof it as chrome, then it works ! (both , on os4 and on mos). What a relief :)
Strange why it didn't crashes same on mos without protect in didOpenCallback, through, but who care :)
@Fab Well,i was too fast to say "it fixed". That protect fix the crash, yes, but websockets still didn't works as they should. I.e. they just disconnects.
If i go to websocket.org/echo.html , then do "connect" on os4 port, then their log form says "disconnect". But if i do same on morphos version, then it say in they log says "connected", and wait till i not press "disconnect" button (through, "Use secure WebSocket (TLS)" also didn't works on morphos and do disconnect, while works on win32's chrome).
So while there is no crash anymore, it isn't here not because all fine, but because it just seems don't do connection.
It i just pure go at bombermine.com and wait till everything loads.
Also tested Joerg's owb : while there is not full websocket implementation its still have some basics as i see by tests, and it still can pass websocket.org/echo.html (tested with plain websocket connections : works. But , with TLS it just crashes with null pointer).
@All Common, where all those skilled ppls who can easy port it all ? Check the files i put in previous post, maybe you will find something.
Edited by kas1e on 2014/2/19 11:20:27 Edited by kas1e on 2014/2/19 11:21:06 Edited by kas1e on 2014/2/19 11:22:30 Edited by kas1e on 2014/2/19 11:24:39 Edited by kas1e on 2014/2/19 11:40:32 Edited by kas1e on 2014/2/19 11:41:57
For sure you know already so you don't need, aniway Just to verify i repeat the test on my system and the websocket.org/echo.html site seems fine on Joerg's OWB 3.32 (atleast no crash pressing the connect/disconnect buttons) but it crash under Odyssey 1.16
Quote:
Crash log for task "OWB" Generated by GrimReaper 53.16 Crash occured in module OWB at address 0x6B53AE6C Type of crash: DSI (Data Storage Interrupt) exception
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
