Does anyone know about getting REALLY long addresses to work in PEB's address book? I'm talking about address for eBay motors that span 4-6 lines when editing the addresses in Notepad. Even dnet won't work if I put in an address beyond the simple stats.dnet.com or whatever it is that gets us to the first page. If I try to use an address to take myself directly to the OGR page, or -worse yet- directly to my personal stats on the OGR page, it just sits there, like the address wasn't even entered.
I had Paul send me the problem URLs and found that the problem was not with the length of the URL, but in the use of the equals sign ("=")---ARexx does not like the use of this symbol in text strings. Thanks to some help from Chris Y., a work around has been found and is implemented in the new version on OS4 Depot (v. 1.3).
If anyone finds any addresses that do not work, let me know, and I'll try to find a way to get them working.
I know, I use it. But it still lets the gif anims play once before they stop. I want an option to not play them at all, because even when they play once and stop it takes a while for some forum pages to become usable. :)
This webcam isn't properly updated past the second reload. Dunno whats wrong here, works with AWeb quite fine.
It's the same in the Linux version of OWB. The page is reloaded every 10 seconds by the META HTTP-EQUIV=Refresh, but the image probably isn't because it's always the same URL (webcam.jpg).
I think I've posted this here and there but I don't remember any constructive reply. This site doen't work well (try to click "login" in the top-right corner of the main page): http://ae-www.technion.ac.il Looks like it's OWB bug, not induced by the porting. The links an input field that are not inside main frame do not resond to the mouse. This happens instead: when mouse hovers over location inside the "inner" frame thet equal to locations of objects that belong to the upmost frame (relative-to-top-left-of-the-upmost-frame) the objects in the upmost frame respond (say location (x,y) is inside of "some button" in the upmost, click on the (x,y) inside the inner frame, means absolute location (x+inner_frame.x, y+inner_frame.y), will result in the "some button" to be clicked).
And a feature request: mime-types handling to allow associating the filetypes with external programs.
Keep up the great work! Jack
"the expression, 'atonal music,' is most unfortunate--it is on a par with calling flying 'the art of not falling,' or swimming 'the art of not drowning.'. A. Schoenberg
This webcam isn't properly updated past the second reload. Dunno whats wrong here, works with AWeb quite fine.
It's the same in the Linux version of OWB. The page is reloaded every 10 seconds by the META HTTP-EQUIV=Refresh, but the image probably isn't because it's always the same URL (webcam.jpg).
Jack wrote: I think I've posted this here and there but I don't remember any constructive reply. This site doen't work well (try to click "login" in the top-right corner of the main page): http://ae-www.technion.ac.il Looks like it's OWB bug, not induced by the porting. The links an input field that are not inside main frame do not resond to the mouse.
[...]
I saw this before, back when we didn't have the built-in navigation toolbar, and I used a page with a frameset where the top frame was a toolbar and an URL field, and the rest contained the loaded page. Loading my own page on http://nbache.dk and going to one of the subpages, which are in themselves framesets, led to the links in the largest frame not being usable, instead the ones on the left frame at the same Y-position were followed (IIRC).
It seemed to be a problem in the main OWB code (not this port specifically) which makes OWB confused on pages with framesets within framesets. I think someone was going to report it to the OWB team (J?rg? afxgroup?), but I'm not sure if that ever happened?
I had a quick look around in the ticket lists on sand-labs.org, but didn't find anything that looked like it.
Getting lots of these: const WebCore::Cursor& WebCore::waitCursor() not implemented
On a not-entirely-different subject, cookies aren't being remembered across sessions, so I have to keep logging in to amigans.net etc as it won't remember who I am.
Loading my own page on http://nbache.dk and going to one of the subpages, which are in themselves framesets, led to the links in the largest frame not being usable, instead the ones on the left frame at the same Y-position were followed (IIRC).
Yes, same porblem as in your site. Looks like frame indices or smthing like this are mixed up when evaluating the button under the mouse. Looked through tickets too (briefly), no avail.
Jack
"the expression, 'atonal music,' is most unfortunate--it is on a par with calling flying 'the art of not falling,' or swimming 'the art of not drowning.'. A. Schoenberg
URL and titlebar gets confused on some sites. One which shows the problem immediately is http://www.eurogamer.net (it starts showing the title and address of the ads)
The links get a bit confused on the same site - after scrolling down a bit the pointer seems to think it is over links that are above where it is pointing.
The links get a bit confused on the same site - after scrolling down a bit the pointer seems to think it is over links that are above where it is pointing.
That's probably a bug I've fixed (offsets, and therefore links, from wrong frames are used), but currently it doesn't make much sense to work on OWB and release new AmigaOS4 versions of it, the Sand-Labs/Pleyo developers are currently implementing a new OWBAL and a newer version of WebKit will be used for the next OWB milestone (Doduo), which will very likely fix a lot of bugs in OWB but will probably require larger changes in the AmigaOS4 parts as well. Since changes in the current OWB (Blastoise) might have to be reimplemented for Doduo it's better to wait until that's finished, which should be very soon, and after the current AmigaOS4 parts are adapted to the new OWB version continue working on the AmigaOS4 parts with that one.