* The Network Kit now makes use of it for BUrlContext, so we need this
in the public headers.
* Problem caught by the new build bot by compiling the unit tests.
* Each BHttpAuthentication object is locked on all field accesses,
* They are owned by the BUrlContext and never deleted, so there is no
need for reference-counting them,
* The BUrlContext itself is now reference counted, and all BUrlRequests
hold a reference to it.
This makes sure using the BHttpAuthentication objects from requests is
thread-safe.
* Change the semantics of the iterators copy constructor and assignment
operator: they now return a new iterator for the same cookie jar (and
same url for the UrlIterator). They don't try to point to the same
position as the copied iterator. The only purpose of these is to write
code such as:
Iterator it = jar.GetIterator();
so having a full copy isn't that useful.
* The per-domain cookie lists are now protected with a read-write lock.
The iterators retain a read lock while they are handling cookies from
that list. They get a write lock when doing Remove. Adding a cookie to
the jar also gets the write lock for the matching list
* Fix a memory leak when adding a new domain-list to the jar failed
* Simplify the declaration of the PrivateHashMap type (it would be
even simpler if HashMap was a public API)
* The domain hashmap is now a SynchronizedHashMap. It is locked as long
as an Iterator or UrlIterator exists, which may be a problem as these
are public APIs. Writing safe iterators for an hashmap with concurrent
accesses is not easy, so the API could be modified to return a list of
domains and a list of cookies for a given domain or URL instead. This
would suit the intended uses just as well.
* The jar now store const cookies, so there is no need to lock them for
access/modification. Updating a cookie is done by replacing it with
another one in the jar (with the same domain and value). There is still
the problem of deleting a cookie while other threads may still access
it, this will be fixed by making cookies BReferenceable.
* That change did not make any sense, as the floppy-boot images
can't be built in debug mode anyway (the result is much too large).
This reverts commit 911821275a.
* Word 105 of ATA IDENTIFY should contain the maximum number of block
ranges the device supports, but it always supports at least a single
one.
* This change lets the trim command do something on Virtual Box.
* This tests requires some private APIs which have been changed, it
needs to be rewritten.
* I'm also not sure if it's still possible to work on a copy of the MIME
* database to avoid messing with the system one.
If you have the Desktop window open when you switch to spatial
mode this will now close the window. You aren't allowed to have
the Desktop open in 2 places symultaneously in spatial mode.
... in a few more cases.
If you are in spatial mode and you double-click on the Desktop folder
it activates the Desktop putting all other Tracker windows in the
background.
If you are in browser mode and you double-click on the Desktop folder
it opens the Desktop folder in the current window.
If you issue 'open ~/Desktop' from Terminal or if you have Expander set
to open the expanded folder and you expand something on the Desktop
it won't open the Desktop folder in its own window in either spatial or
browser mode.
This patch alters Trackers behavior to open the Desktop folder in its own
window in these cases when you are in browser mode.
One might argue (as a few have on IRC) that this behavior should also
happen in spatial mode, but, this patch does not alter the behavior of
spatial mode. In spatial mode opening the Desktop folder with
'open ~/Desktop' or extracting a zip file with Expander on the Desktop
simply activates the Desktop pushing all other Tracker windows into the
background state.
Fixes#10929
* thanks to Ingo for suggesting the idea, quoting him:
"by holding sVnodeLock read-locked, get_mount() ensures that fs_unmount() can't
process the nodes. If it is already past that point, the root node check
(not NULL, not busy, ref count > 0) is supposed to detect that. But it doesn't
look like this can work. fs_unmount() doesn't set the root node to NULL (the
root node field is NULL only during a short period in fs_mount()), but it just
frees the nodes after releasing sVnodeLock. So the not busy and ref count > 0
checks could already access freed memory".
* tested OK, this fixes#10522.
* replaced mount->root_vnode by the local variable with the same value.
* There is a SimpleTest in AlertTest.cpp, and an UnitTest in
balert/AlertTest.cpp. They ended up with the same grist as they are
built from the same jamfile. Rename one of them to avoid this.
* The Udf namespace was removed from the headers, but not all the
implementation files
* kernel_cpp.h is not actually used
* TRACE_ERROR can't be set to dprintf when building as part of the test
(and not as a kernel add-on)
First step on the way to get jam -q unittests to work again...
* Cookies sometimes come with the UTC timezone, or no tz info at all.
* No other timezone seems to be used
This allows better matching of cookies which would otherwise be kept
only as session cookies.
... try 2 without a spurious \
sorry for the noise.
From the commits list (Ingo) <<-EOF
> Terminal crashes because fView is not connected to App Server when
> this is called so calling fView->GetMouse() is not allowed.
The interesting questions therefore are:
1) Why is the view not attached?
2) Why is it in the hyper link state?
1) is because the BTabView removes the non-selected tabs instead of just
hiding them.
The reason for 2) is that the tab was opened with Cmd+T (the bug is not
reproducible when the tab is opened via menu item). Pressing Cmd causes
hyper link state to be entered and switching to the new tab will leave
the view in that state due to 1).
Possible solutions:
* TermView::_VisibleTextBufferChanged(): Call state hook only when attached
to window. All other occurrences are safe as they are in BView hooks.
* Leave the hyper link state when the view is detached from the window. A
new dummy state could be active as long as the view is not attached, though
using DefaultState would be harmless as well.
EOF
I chose solution 2 using DefaultState rather than creating a new dummy state.
Thanks Ingo.
Fixes#10902
From the commits list (Ingo) <<-EOF
> Terminal crashes because fView is not connected to App Server when
> this is called so calling fView->GetMouse() is not allowed.
The interesting questions therefore are:
1) Why is the view not attached?
2) Why is it in the hyper link state?
1) is because the BTabView removes the non-selected tabs instead of just
hiding them.
The reason for 2) is that the tab was opened with Cmd+T (the bug is not
reproducible when the tab is opened via menu item). Pressing Cmd causes
hyper link state to be entered and switching to the new tab will leave
the view in that state due to 1).
Possible solutions:
* TermView::_VisibleTextBufferChanged(): Call state hook only when attached
to window. All other occurrences are safe as they are in BView hooks.
* Leave the hyper link state when the view is detached from the window. A
new dummy state could be active as long as the view is not attached, though
using DefaultState would be harmless as well.
EOF
I chose solution 2 using DefaultState rather than creating a new dummy state.
Thanks Ingo.
Fixes#10902
Also derived from Opera test suite.
* Fix nbsp instead of space in some tests (I shouldn't have copypasted
these...)
* Add most of the advanced tests from Opera. This exposed several bugs
in the cookie code (all fixed) as well as strptime and strtol (tickets
opened)
* All the cookie2 tests are skipped. I didn't find any use of it on the
internets, so it doesn't seem useful to implement it.
* The last two tests sets are still missing. I'll add them next week.
