Latest Bugs & Tasks
Fixed in https://github.com/haiku/webkit/commit/4b3e388e6e5cf61bf8a33aba54182c4d63205e64.
Drawing the scrollbar modified the view state, breaking the border-radius drawing. Any box with border-radius and a scrollbar would be affected.
- Create an additional user for ssh access
- Ssh to your haiku computer, and try to run a BApplication
- The application silently stops.
Syslog has this message:
DAEMON 'app_server': Cannot initialize Desktop object: General system error KERN: Could not initialize graphics output. Exiting.
This happens with vim, unzip, and DumpRenderTree. It's either because of using ssh, or because the new user doesn't have the right permissions. At least a warning to standard
output, instead of the syuslog, would be nice. A fix to make this working would be even better.
webpositive crashed, could be a duplicate of another crash, not sure why it crashed, attaching crash report.
version 46955 new webkit build.
Fixed in hrev46966
Fixed in hrev46973
Fixed in hrev45401. The white flashing is normal redrawing behavior. Some more Deskbar refactoring is still in progress but the lockup bug described by this ticket should be gone.
I'm assuming this one got fixed in hrev46195, please reopen if you experience this crash again.
closing this ticket as the problem described by ticket is solved.
That's actually intentional. When you have an application bundled with required libraries, those are supposed to fit anyway and there's little point in adding the extra directory level for the architecture.
It is also necessary to do it this way, so application zips with bundled libraries work regardless of whether the application's architecture matches the primary or the secondary architecture.
This is hrev46955.
The GMail webinterface buttons at the top (Refresh, or with a marked email, Archive, Spam, Delete etc.) need two clicks before doing the action. The first click just tints the button (giving it focus?).
E.g., when building webkit and dropping WebPositive in the folder, it should load libWebKit.so.1 from %A/lib/x86 on a gcc2h system; however, it only searches in %A/lib, failing to find the library in question.
Summary says it all. I am attaching a patch that gets it sorted as I don't think I got developer access after we moved to git. if someone could be kind to patch it, that would be great.
I have an 8GB bfs formatted image file mounted, and my system partition has about 3GB free. My system also has 8GB of RAM. I've also disabled Virtual Memory, but the problem also occurred with Virtual Memory enabled.
It seems like writes to the mounted image file are causing some weird issues in the file caching layer. And even though looking at process controller, the memory usage never seems to appear to exceed 500MB, large writes to the mounted image causes the system to think there is no memory left.
Also, the kernel's "low resource handler" thread hammers a single core at near 100% utilisation.
Gets into a state where even reads from the mounted image file appear to be corrupted.
/Cabinet/webkit> git checkout HEAD --force error: failed to read object 3e482c427f57a47f262816900de4ca655b322792 at offset 98195304 from .git/objects/pack/pack-1d8534f61de156ee015c1949b78755305f4e2ebb.pack fatal: packed object 3e482c427f57a47f262816900de4ca655b322792 (stored in .git/objects/pack/pack-1d8534f61de156ee015c1949b78755305f4e2ebb.pack) is corrupt /Cabinet/webkit> git pull bash: /bin/git: Out of memory
After a reboot, git no longer complains about corrupted files the first time through (of course, a few file system operations later, what once worked ends up being reported as corrupted again).