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.
* 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
