NAVIGATION_REQUESTED notification again from the FrameLoaderClient, this way
we can try to fetch the icon even earlier.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@259 94f232f2-1747-11df-bad5-a5bfde151594
necessary. The only usable effect as of yet is that favicons arrive at the
BrowserWindow. Favicons are stored in a database and are not fetched when they
alreary exist. The application is expected to try and fetch an icon for a given
url. This is currently done in BWebWindow when the URL for loading has been
initiated. Otherwise it fetches the URL upon the new ICON_RECEIVED notification
from the FrameLoaderClientHaiku. In any case it ends up at BWebWindow::IconReceived(),
so derived classes don't have to worry about the difference. In any case, via
BWebSettings, icons can also be fetched manually, like for the forthcomming
autocompletion text control.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@257 94f232f2-1747-11df-bad5-a5bfde151594
it so much, since it somehow looks alien for no /really/ good reason. Maybe
I'll integrate this option into the settings, when I get to those.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@253 94f232f2-1747-11df-bad5-a5bfde151594
open a new file or url, check if there is already a window open on the current
workspace, and if so, open a new tab in that window and bring it to front.
ArgReceived() now reuses RefsReceived(), which has been extended to handle
"url" string fields in the message, since ArgReceived() may also be asked to
open urls and not only local files. The LOAD_AT_STARTING mechanism, which
turned out to be broken for multiple args anyway, could be replaced, since
RefsReceived() already buffers the message when it has been called earlier
then ReadyToRun().
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@244 94f232f2-1747-11df-bad5-a5bfde151594
gone when a BWebDownload wanted to use it. Now the class is more self-sufficient.
One example of the problem was clicking a link that opens a blank page, then
closing that page while the download was still loading. 1) The download finished
notification never arrived and 2) clicking to cancel the download would crash
after the download finished, since really it had already selfdestructed...
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@240 94f232f2-1747-11df-bad5-a5bfde151594
Original commit message of r238:
Split up WebPositive from HaikuLauncher. HaikuLauncher is back to it's simple
self. WebPositive uses a new WebPositive folder in config/settings. Otherwise,
everything should be as before. LauncherWindow and LauncherApp have been renamed
and cleaned up for the Haiku coding style.
Edit history with this rename commit to preserve history as we will git-filter --subdirectory-filter the WebPositive directory. The HaikuLauncher directory was renamed to WebPositive trough the past history with git-filter.
I've split the 32-bit dependent IDT setup code and ASM interrupt handlers to
the 32 subdirectory, arch_int.cpp now contains only the generic hardware
interrupt handling code.
For now I've just put all the stub functions that are needed to link the
kernel into a file called stubs.cpp. I've not yet moved across the interrupt
handling code or the ELF64 relocation code to the x86 directory. Once those
have been moved I can get rid of the x86_64 headers/source directories.
- repnz movsb turns out to not actually be a legal instruction,
resulting in various strings being copied incorrectly, leading to
random crashes in various places. Rework to use loop instead.
Thanks to Alex Smith for helping review changes and offering
improvements.
- Minor cleanups.
- Fixes#8650 properly.
Not many changes seeing as there's not much x86_64 stuff done yet. Small
differences are handled with ifdefs, large differences (descriptors.h,
struct iframe) have separate headers under arch/x86/32 and arch/x86/64.
Since x86 and x86_64 share a lot of common code, x86_64 kernel sources/headers
are going to reside under headers/private/kernel/arch/x86 and
src/system/kernel/arch/x86 along with the existing x86 code. This commit
changes the build system to handle this. A new variable, TARGET_KERNEL_ARCH,
has been added. This is the name of the kernel/boot architecture directory
name, set to x86 on both x86 and x86_64. This is now used in all places where
TARGET_ARCH was used to get to kernel arch sources/headers (I've changed
everything necessary as far as I can tell). Kernel won't build for x86_64
at the moment as the sources have not been merged, loader does.
- Replace arch_cpu_user_strlcpy() and arch_cpu_user_memset() with x86 assembly
versions. These correctly handle the fault handler, which had broken again
on gcc4 for the C versions, causing stack corruption in certain error cases.
The other architectures will still need to have corresponding asm variants
added in order for them to not run into the same issue though.
The caches contain pointers into memory allocated by debug_malloc()
that come from a pool that is destroied once the command returns.
We therefore have to ensure that all such pointers are cleared in all
cases before returning from the command or we will run into errors
when executing the next commands.
Using the qrwebpost debugger command one can initialize an id for
subsequent QR codes. All QR codes generated following such an
invokation produce URL QR codes that link to an online service that
concatenates all data with the same id and later allows it to be
displayed/downloaded in one piece. This makes collecting larger amounts
of data more convenient. Note though that the URL encoding does waste
space and therefore reduces data density, causing more QR codes to be
generated for the same amount of input data.
* Generates QR codes using the qrencode library functions and prints them
using terminal escape sequences and the special "block" characters.
* Supplies a static QR buffer that can be used to accumulate output for
later conversion into QR codes.
* Adds qrencode debugger command that allows to generate QR codes for
arbitrary strings.
* Adds qrappend, qrflush and qrclear to manipulate the QR buffer.
qrappend can be the target of a pipe to accumulate output from other
commands. qrflush causes the QR buffer to be encoded and cleared and
qrclear only clears the QR buffer.
* Adds qrconfig that allows changing the QR code version, determining
what size QR codes are to be used.
Characters 17, 18 and 19 (device control 1, 2 and 3) become "full block",
"upper filled block" and "lower filled block". Using back- and foreground
color inversion these could be reduced to a single "half block", but
having them available as idividual chars is more convenient.
The kernel strdup will still be used, as the local symbol doesn't
override that. Since we must not use strdup from within the kernel
debugger (as it does malloc from the normal heap), force the use of
the internal strdup that gets redirected to debug_malloc.
