* 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.
* An empty "expires" field results in a session cookie, rather than
rejecting the cookie altogether
* A page can set a cookie it is not allowed to access (for example in a
subdirectory of where the page is located). Separate IsValidForUrl and
_CanBeSetFromUrl to perform the appropriate checks in each case.
* Limit cookie path to 4096 characters. As a result of the previous
change, a page would be allowed to set a cookie with an aribrarily long
subpath, wasting disk space and RAM by growing hte cookie jar.
* Don't allow path with . or .. elements. These are a source of
confusion and are not needed.
* Reset the cookie fields when parsing failed. This does not matter when
using the cookie jar, but is useful when working directly with
BNetworkCookie.
strptime can return non-NULL values even if it only parsed part of the
string. This was sometimes making us use the wrong format. Now we try
all formats and checks how much of the string strptime managed to parse.
We stop when it has parsed a big enough part of it.
Terminal crashes because fView is not connected to App Server when
this is called so calling fView->GetMouse() is not allowed. We could
perhaps check to make sure that fView is connected to App Server by
checking that fView->Window() != NULL, but, a better way to handle this
is to grab the already set fLastClickPoint variable from fView
which eliminates the need to grab the current mouse position again.
Worst case scenario is that fLastClickPoint hasn't been set in which
case Terminal won't find anything to highlight or unhighlight.
Also check to make sure that fView != NULL here for good measure.
Fixes#10902
* BString::CopyInfo() takes length as second
parameter, not the end-offset. This bug didn't
have any effect, since BString clamps the length.
* ',' is a comma, ':' is a colon.
* When parsing "additionalData" in the loop for
name=value pairs, an empty name is not useful,
continue the loop early.
* "value" may have the length 0, accessing it
with value[0] would not lead to an access violation,
since it just reads the terminating zero (I think),
but it's nicer if the code makes it clear that
value being empty is considered.
* _H() was using a static buffer, in a heavily
multi-threaded situation. I don't think this was
healthy.
* Implement the proposed optimization of using
BString::LockBuffer(). Appending one char at a time
is really bad for peformance. The Base64 encoding/decoding
should really be rewritten as well for similar reasons.
These were getting out of sync and causing trouble, and they are easy to
compute from existing information.
Fixes some problems detected by the testsuite where the user/password or
the host would sometime disappear from the URL.
