Yes everything is working fine with my NUC Intel I5 6I5SYK (year 2017)
Wifi, audio via jack (sometimes it’s bug and need to restart), etc. I didn’t test bluebooth.
If you have some doubts with the hardware, if you own it, you can test with a live USB stick.
Also, when Iceweasel is open, if you shutdown the computer, it wont shut down, but an error message appears with some regret message.
This is very consistent in it’s behaviour.
When Iveweasel is open, you cannot shut down your laptop, gracefully
I am happy we now have a variant of Firefox for Haiku, but it’s still under heavy development, and it shows.
I get severe lockups, high CPU load and lots of crashes in various Wayland and non-wayland related occasions, e.g. the garbage collector.
Just today, with latest Haiku nightly hrev58507, I had this curious issue several times:
In the last step, there is no way back, no Esc, nothing helps, just hard reboot.
This is not to offend anyone, @KENZ and all those who contribute and help are doing an awesome job.
I just don’t want to over-hype this and spread wrong assumptions.
By definition, it cannot compete with WebPositive on the efficiency front, so I’m really surprised you have the opposite impression.
For me, a native, lightweight browser to quickly get documentation and various infos is a hard requirement, something that Konqueror and Safari were in the beginning.
Firefox/Iceweasel is the SUV of the Web, with all advantages and disadvantages.
WebPositive is the - dare I say - Tesla (just symbolically) in comparison.
Every tool has its strenghts and use.
Does KDL work in that state? I think the blue borders are caused by the app_server thinking that ctrl and alt (from ctrl alt del) are continioung to be held while you have let go in actuallitty.
Oh so it’s a visual app_server debugging mode?
You mean manually jumping into KDL via Ctrl+SysReq?
Depends. Are we talking about these blue borders or something else?
https://www.haiku-os.org/docs/userguide/en/gui.html#move-resize
edit: Yes, i ment jumping into kdl with the keyboard
Yes these are the ones. Interesting, didn’t know that shortcut…
In any case I cannot control Tracker with the mouse anymore then, it’s trapped in keyboard mode.
Yeah, in this mode all mouse events are only interpreted as left click for move and right click for resize.
Ideally this should be reoslveable, for example with an app_server restart. But iirc this doesn’t actually work with apps reconnecting and such.
On my NUC, I’ve the opposite experience for the moment (note : I’m on R1 beta5 and not on nightly) :
If that happens on specific pages please open a ticket (As this is then a freezing bug), but in general this is a bit of a systemic problem since a single misbehaving page will freeze all others too. With webkit2 this will be fixed, and we are making progress towards this, but we aren’t there yet. : )
Ok I got this issue again today with latest Haiku hrev58510.
This time I was able to take a debug report and kill the rogue Iceweasel process, but it was not easy:
ps in Terminal froze !Between all the assembly there is some useful info after all: (will probably move this to a proper bug report if not already known)
Active Threads:
thread 536: IPC I/O Child
thread 540: pool-spawner
thread 541: gmain
thread 545: Socket Thread
thread 546: HTML5 Parser
thread 547: StyleThread#1
thread 548: StyleThread#2
thread 549: StyleThread#3
thread 550: StyleThread#4
thread 551: StyleThread#5
thread 552: JS Watchdog
thread 554: Timer
thread 555: RemVidChild
thread 556: ImageIO
thread 557: Worker Launcher
thread 558: Backgro~Pool #2
thread 559: ImageBridgeChld
thread 560: ProcessHangMon
thread 566: team 527 debug task
thread 527: MainThread (main)
state: Exception (Segment violation)
...
|||0x7f59219755c0|0x30fdfab089|IPC::ParamTraits<mozilla::psm::Certificate>::Read(IPC::MessageReader*) + 0xd9 |
|---|---|---|---|---|
|||0x7f5921975670|0x30fe01c9c0|_ZN7mozilla10MozPromiseISt10shared_ptrIN16content_analysis3sdk6ClientEE8nsresultLb0EE9ThenValueIJZNS_15contentanalysis15ContentAnalysis21RunAnalyzeRequestTaskERK6RefPtrI25nsIContentAnalysisRequestEblRKSB_I26nsIContentAnalysisCallbackEE3$_0ZNSA_21RunAnalyzeRequestTaskESF_blSJ_E3$_1EE10DisconnectEv + 0 |
|||0x7f5921975690|0x30fe01c568|already_AddRefed<mozilla::CancelableRunnable> NS_NewCancelableRunnableFunction<mozilla::contentanalysis::ContentAnalysis::CancelWithError(nsTString<char>, nsresult)::$_0>(char const*, mozilla::contentanalysis::ContentAnalysis::CancelWithError(nsTString<char>, nsresult)::$_0&&)::FuncCancelableRunnable::Run() + 0x4a8 |
|||0x7128d195770|0x30fe017b0e|/boot/system/apps/Iceweasel/lib/libxul.so + 0x349eb0e |
...
thread 539: Iceweasel
state: Exception (Invalid opcode exception)
Frame IP Function Name
-----------------------------------------------
0x7fcb8d49e390 0x30fdfc5abf mozilla::ContentBlockingAllowListCache::EnsureInit() + 0x34f
...
|||0x7fcb8d49e3c0|0x30fed23645|prio::flp::ProveShimGadget$LT$F$GT$::new::hb4101436f8db57aa + 0x135 |
|---|---|---|---|---|
|||0x7fcb8d49e3e0|0x30fecfd8fc|chrono::format::format_inner::h43779f84e2b3a33b + 0x81c |
|||0x7fcb8d49e420|0xf557659e69|__cxa_finalize + 0x159 |
|||0x7fcb8d49e440|0xf55765a022|exit + 0x12 |
|||0x7fcb8d49e448|0x21d4eadafc0|Application::MessageReceived(BMessage*) + 0 |
|||0x7fcb8d49e440|0x7fcb8d49e500|? |
|||0x7fcb8d49e510|0xc46aff4d33|BLooper::_QuitRequested(BMessage*) + 0x33 |
|||0x7fcb8d49e560|0xc46aff526e|BLooper::task_looper() + 0x28e |
|||0x7fcb8d49e580|0xc46aff47fb|BLooper::_task0_(void*) + 0x1b |
|||0x7fcb8d49e5a0|0xf5575e1167|thread_entry + 0x17 |
|||00000000|0x7fe67e966258|commpage_thread_exit + 0 |
0x7fbe6bfa3bb0 0x30fdf84322 nsClientAuthRememberService::DeleteDecisionsByHost(nsTSubstring<char> const&, JS::Handle<JS::Value>, JSContext*) + 0x132
...
0x7fbe6bfa3be0 0x30fe5f1cbc js::frontend::GeneralParser<js::frontend::FullParseHandler, char32_t>::ifStatement(js::frontend::YieldHandling) + 0x46c
0x7fbe6bfa3c20 0x30fe5fb009 js::frontend::GeneralParser<js::frontend::FullParseHandler, char32_t>::bindingIdentifier(js::frontend::DeclarationKind, js::frontend::YieldHandling) + 0x89
0x7fbe6bfa3c80 0x30fe5f272f js::frontend::GeneralParser<js::frontend::FullParseHandler, char32_t>::forStatement(js::frontend::YieldHandling) + 0x6bf
0x7fbe6bfa3e60 0x30fe021216 mozilla::IdentityCredentialStorageService::BlockShutdown(nsIAsyncShutdownClient*) + 0x76
0x7fbe6bfa3ea0 0x11cfe791fc9 _pt_root + 0xb9
0x7fbe6bfa3ec0 0xf5575f0925 pthread_thread_entry(void*, void*) + 0x15
00000000 0x7fe67e966258 commpage_thread_exit + 0
Semaphores:
ID Count Last Holder Name
------------------------------------------------------------
33268 0 0 some BBlockCache lock
33269 0 0 token space
33270 0 0 BLooperList lock
33271 0 0 AppServerLink_sLock
33272 0 0 some BLocker
33273 0 0 some BLocker
33274 0 0 Catalog
33275 0 0 LocaleRosterData
33276 0 0 some BLocker
33283 0 0 some BLocker
33284 0 0 BMediaRoster::Roster locker
33285 0 0 port pool
33286 0 0 media theme lock
33287 0 0 add-on manager
33288 0 0 shared buffer list
33289 0 0 media plugin manager
33319 0 0 BMessageQueue Lock
33320 0 0 AppLooperPort
33333 0 0 screen list
33334 0 0 clipboard
33335 0 0 width buffer
If nothing works (reboot or closing Iceweasel) use:
Alt+SysReg+D
to get to the KDL, and type reboot to restart
or type cont to get back to the Desktop (which wont help here)
or type bt to get a backtrace, make a picture with your phone and sent it here!
This sounds like the issue that @Nexus-6 reported on the bugtracker, it’s somehow a Haiku regression. I haven’t reproduced it yet (but I have some devices on bare-metal here that I didn’t test yet.)
We might have restricted the suspect hrev to 58503, KDL does not give me any insight except that some apps seem stuck in wait for a condvar or a semaphore.
These commits seem two good candidates, maybe?
Ah then I had the wrong keyboard shortcut in mind and will try again, sadly happens very often currently anyway… like 1 in 3 times.
It’s good to know !
Just for SysReq I had to use [Fn] key on this keyboard 
Update now to hrev58517 and the bug is solved by waddlesplash yesterday!
Same here it seems, didn’t encounter this bug anymore but didn’t test much.
I’ve just merged changes (in hrev58524) that fix stack trace generation in Debugger for any application or library built with Clang/LLD, which includes “Iceweasel”, so now debug reports generated for it should be much more useful.