Commit by stippi :: r307 /webkit/trunk/WebKit/haiku/API/WebPage.cpp: (link)

Quick hack to enable the cookie handling in the CURL backend. This at least
allows some persistency across sessions.

Commit by stippi :: r306 /webkit/trunk/WebKit/haiku/API/NetworkCookieJar.cpp: (link)

Added TODO about why the current implementation is broken...

Commit by stippi :: r305 /webkit/trunk/WebKit/haiku/API/ (NetworkCookie.cpp NetworkCookie.h): (link)

Added a whole bunch of setters and getters... not used anywhere, yet.

Commit by stippi :: r304 /webkit/trunk/WebCore/platform/haiku/CookieJarHaiku.cpp: (link)

Included optional tracing and fixed the build. Sorry about that.

Commit by stippi :: r303 /webkit/trunk/ (13 files in 8 dirs): (link)

 * Added a class CookieJarClient to WebCore's CookieJar.h which provides the
   same functionality as the global methods for managing cookies. This is only
   enabled for the Haiku platform. Since the global cookie methods get a Document
   pointer, I envision, the CookieJarClient could eventually be a member of
   Document instances. It would then be passed upon WebCore::Page creation.
   Still waiting on feedback from other WebKit developers on this one. This change
   is more elegant than what the Qt port does, which is to use WebKit classes in
   WebCore (layering violation). Right now, a single global instance of a
   CookieJarClient can be assigned.
 * Implemented CookieJarClientHaiku which uses a BNetworkCookieJar to forward
   the requests. Eventually, the behaviour could be browser specific.
 * Added all the necessary wiring to BrowserApplication to make the cookie jar
   persistent.
 * TODO: Actually parse cookies and handle at least the expiration date, but
   other stuff like matching the domain of the cookie and the URL and "HTTP-only"
   cookies seems important as well.

Even though I have confirmed that cookies are stored and restored correctly,
and also retrieved via the global cookie methods, I can see no change in browser
behaviour. For example enabling "Stay signed in" on googlemail.com does not work
in WebPositive, although BeZillaBrowser automatically logs in in a new session
when surfing to googlemail.com. No idea if this is even implemented with
cookies, although it seems like it should be.

Commit by stippi :: r302 /webkit/trunk/WebKit/haiku/WebPositive/autocompletion/TextControlCompleter.cpp: (link)

Use the "bytes" member from the keydown message in order to get mapped keys.
The 8 and 2 on the number pad would not work in the URL bar otherwise, since
those map to "B_UP_ARROW" and "B_DOWN_ARROW" as raw char.

Commit by stippi :: r301 /webkit/trunk/WebKit/ (7 files in 2 dirs): (link)

Some work towards a persistent cookie jar implementation. Since it will be
browser specific, there needs to be a way to influence the cookie jar behavior
from within the browser. Nothing is wired, yet.

Commit by stippi :: r300 /webkit/trunk/WebKit/haiku/WebCoreSupport/ (2 files): (link)

Make BWebPage accessible. Will be needed in code that needs to get to it
from within WebCore. (The Qt port does it like that, though perhaps I can find
it better solution, as it's a layering violation.)

Commit by stippi :: r299 /webkit/trunk/WebKit/haiku/ (6 files in 2 dirs): (link)

Finally wrapped my head around the ref counting problem of WebCore::Frame
instances. I've confirmed everything working and compared reference counts
with the Gtk port. Now all frames are correctly free'd. Introduced BWebFrame::
Shutdown(), to ballance allocations in the same class file.

Commit by stippi :: r298 /webkit/trunk/ (3 files in 3 dirs): (link)

Use the new system cursors. This will force mmlr to upgrade his server, which
will in turn also get rid of the libjpeg version mismatch problem in the
nightlies... :-D

Commit by stippi :: r297 /webkit/trunk/WebKit/haiku/ (4 files in 2 dirs): (link)

Documented a memory leaking problem with the shutdown process of pages. There
is one reference too many on the WebCore::Frame. Responsible for getting rid of
any BWebFrame instances is the FrameLoaderClientHaiku, as in other ports.
Added tracing which shows the problem.

Commit by stippi :: r35782 /haiku/trunk/ (12 files in 5 dirs):

 * Added BCursorID enumeration in App Kit's Cursor.h and new constructor which
   takes such an id.
 * Reused the existing mechanism to to have hardcoded tokens for the system
   cursors, i.e. removed cursor_which enumeration from ServerProtocol.h and
   used BCursorID where cursor_which was previously used.
 * Reworked CursorManager.h and CursorSet.h accordingly and removed some methods
   that where intended to replace system cursors with client cursors, since
   those would break the reference counting and forget to maintain the cursor
   list.
 * Replaced the cursors in CursorData.h/cpp with the new ones I just designed.
 * Removed HaikuSystemCursor.h and HaikuLogo.h from the source, as those are/were
   no longer used.

I hope I will not get too much beating for this one... :-) I know the new
default cursor is slightly larger, but I believe the old one was just too small.
Also I noticed that the cursor may be slightly too dark, at least the old one
seems noticeably brighter when compared side by side (the new one has a slight
gradient). That is something I may correct at least. Otherwise I hope nothing
is broken, I've tested in QEMU and so far everything works as intended.

Commit by stippi :: r35781 /haiku/trunk/data/artwork/cursors/ (6 files):

• Tweaked angle of index finger.
• Removed the outline at the hand wrist.

Commit by stippi :: r35778 /haiku/trunk/data/artwork/cursors/ (ResizeNorthEast ResizeNothEast):

Fixed file name.

Commit by stippi :: r35777 /haiku/trunk/data/artwork/cursors/ (ResizeNorthEast ResizeNorthWest):

Fixed file name

Commit by stippi :: r35776 /haiku/trunk/data/artwork/cursors/ (27 files):

Designed a whole bunch of cursors.

Commit by stippi :: r35772 /haiku/trunk/ (13 files in 7 dirs):

• Indentation update in DateTime.h
• Extended BTime, BDate and BDateTime with archiving functionality.
• Adjusted code which uses these classes, since including DateTime.h already imports the classes from the BPrivate namespace.
• Moved DateTime.h into Support Kit. It is still in the BPrivate namespace, as I am uncertain what to do with time_type and diff_type. I'd favor moving the constants into the classes itself. Possibly removing the B_ prefix from them. Feedback welcome.

Commit by stippi :: r296 /webkit/trunk/WebKit/haiku/API/WebSettings.cpp: (link)

Close the icon database properly when shutting down.

Commit by stippi :: r295 /webkit/trunk/WebKit/haiku/ (6 files in 2 dirs): (link)

• Use a different deletion strategy for the BWebView. Since the BWebPage will delete itself in the application thread, we cannot delete the BWebView before this happens in the window thread. Now BWebPage is repsonsible for deleting the view.
• Also make sure that there are not still loaders running on the frame. Since the timer messages arrive in a different handler than the BWebPage handler, the timer functions being called could operate on stale pointers. I am not sure why WebCore doesn't make sure of this itself. Perhaps we are not supposed to delete something directly, but via reference counting. Though I am not sure what it would be, since WebCore::Page is not reference countable. Maybe the frame... need to investigate. After all, there could be other timers in the queue besides loading related ones.

Commit by stippi :: r294 /webkit/trunk/WebKit/haiku/WebCoreSupport/ChromeClientHaiku.cpp: (link)

Check for "null" requests. Prevents a crash when trying to load the resource
later. As experienced when clicking to close the funny "You are using an old
browser, use the new Internet Exporer!" banner that slides from the top on
GMX.net.