Well, it seems the implementation for strptime_l will be exactly what was done manually:
So, yes, we should do it, but it doesn’t really make things better or cleaner, since uselocale is in fact a thread-local function (if I read things here correctly).
To report to anyone interested: one of the fixes (the use of the POSIX locale even if the user is currently using another) was merged a few days ago. The other (adapting musl’s strptime to play nice with Haiku, thanks @Grumpy) was submitted a few days ago as well and is waiting for approval. As soon at that one lands WebPositive and cookies should start getting along together. Stay tuned.
BLooper (BApplication is inherited from BHandler) do not own attached BHandler’s.
Thanks for the input. I’ll have that in mind when the time comes for implementing that in WebPositive. For now I’m just glad to announce the issue mentioned in the topic is fixed in hrev56454 (I’m posting this after a reboot without the need to log in again, hooray!). Thanks to everyone that helped with suggestions or reviews, I keep learning from you!
Is this the same issue as #15625 (After using "Open Link in new window" the session is lost) – Haiku ?
If so I can closw the ticket.
Could have been one of the reasons but it seems that it is still here.
Yes it works!
Great work thx very much…
No need to log in to Haiku Forum after reload…
Nice work thx all involved!!!
Testing now other sites!
Looks very good so far, whow a great step! Happy here! 
No, that one predates the regressions in strptime.
Since you only fixed one of the two most annoying Web+/Webkit bugs (
#15625: After using “Open Link in new window” the session is lost is still with us), you’re not yet on the throne. Let’s make you “Prince of Code” for now. 
Seriously, thanks a lot for that fix! 
I guess titles are only for people who post their work on the forum 
Awww, you can be our Code Jester. 
I will be chasing that one to reclaim my kingdom then 
, but it seems to be on Haikuwebkit side and I f****d up so I need to compile that whole beast again.
It seems to be the most used communication channel nowadays, so it’s the easiest way to get reviews and testing, and my code seriously needs both. It’s not for the title… now get back to work, subject of the kingdom
If anyone wants to join the hunt for #15625 (After using "Open Link in new window" the session is lost) – Haiku I left a comment there with my findings (I’m secretly hoping for another @Grumpy intervention that saves the day)
@PulkoMandy already merged the patch a few days ago, so it should be fixed in the next HaikuWebkit release.
I’m now looking at replacing Webkit’s default context menus for something more useful (which will allow us to choose between opening links in a new page or window, would be easier to translate, etc) but I don’t even know where to start. Should I derive ContextMenuProvider? Maybe you already looked into this and can give me some hint. For the life of me I can’t figure out where to write this without touching Webkit’s platform-independent code (which I obviously shouldn’t).
Thanks again!
I don’t know, I think there was some code to add extra entries to the menu but it never really worked? ContextMenuProvider sounds like a good place to start. Usually I look at other versions of WebKit to see if they have something similar and how they achieve it.
We are reaching the limits of what WebKitLegacy is able to do here. The reason is, these days it is only used for an embedded web view in some old iOS apps, and kept alive in WebKit only for that purpose. So it only supports the kind of menu you’d get there. And on the other side of things, in the WebKitLegacy API there is no distinction at all between tabs and windows, so we have to inject that somehow.
We would have a lot more flexibility with WebKit2, but as far as I know no one made progress recently on trying to get that running.
That’s why I don’t really want to put more effort into improving the WebKitLegacy code myself, knowing that someday it will be replaced. I’m happy to have someone disagree with that and take care of it, however. And it also means I don’t have plans for upstreaming the WebKitLegacy parts of our port, nor would WebKit upstream want to include them anyway. So, if you need to do something that would break other ports in the WebKitLegacy area, that may be OK?
Well I happen to agree with you. Obviously the tasks of writing a context menu and making the switch to WebKit2 are not even remotely comparable, but I’d rather put the effort in something meant to last. Since these two annoying bugs are now fixed, I’ll follow your advice and rebase the gsoc branch, see what breaks and what can I do from there with the little C++ I know.