On Wed Sep 4 15:16:26 2024 +0000, Jacek Caban wrote:
BTW, it's the same with `handle_load`. Do you also want me to move
this to HandleEvent there, instead? That sounds like an improvement, yes.
Any ideas how I should proceed? I don't want to waste too much time on
trying things that won't be accepted. I don't know, it indeed looks like a complication. We could maybe have a concept of binding tasks, make sure they don't interfere with anything that could end up doing any notifications and process them in such cases. I'm open to better ideas...
And lastly for `SuperNavigate`, I just found it out during testing
various things, else the new test would fail. I can remove it. Do you have other way to interpret that test that's added in the commit? No, I don't have a better interpretation without deeper look. It's probably best to just drop if if it doesn't fix anything.
This is a repost of an email I sent on Monday that clearly didn't come through (and it isn't even using the wine-gitlab bridge, since I replied to the gitlab notification itself; I wonder when this will get fixed because it's extremely annoying and it's *only* gitlab that has issues).
---
For sync XHRs it seems pretty complicated due to gecko internals. For example, my idea was to process tasks at a given "depth level" only, or those pushed on such depth level (which gets changed on a sync XHR, and otherwise is zero). This means only sync XHR tasks get processed in the sync XHR. In theory it sounds fine and correct, but the sync XHR tests fail.
That's because those tests first create two async XHRs and then a sync XHR. It appears that gecko will simply hang if we don't process the async XHR tasks in the sync XHR message loop…
So maybe we should just execute all tasks at given depth level or before it—but not after. This won't be completely correct for sync XHRs but I think this is a fringe case that doesn't happen in practice? The async operation would be correct wrt. task nesting, and also sync XHRs keep their current behavior when no nested message loops happen, which is important as well.
(currently battling test failures due to an issue I don't understand but yeah)