BUG: Pale Moon misses mouseleave event after fullscreen exit

[Democritus]

Pale Moon version: 28.40 64bit
OS: Windows 7

Bug description:
When Pale Moon exits fullscreen mode that was entered programmatically (via javascript) either again programmatically (after user's action) or by pressing ESC, it misses the next one or more mouseleave and mouseout events.


Steps to reproduce the bug:
1. Visit https://jsfiddle.net/vo3k7gLq/ This is a simple test I uploaded by modifying a three.js example.

2. Move the mouse inside and outside the animation window. You'll see an "INSIDE" or "OUTSIDE" label on the top, depending on whether the mouse is inside or outside the animation window.

3. Left-click inside the animation window (to make sure it has the focus) and leave the mouse there.

4. Press the UP arrow on the keyboard. The animation window will enter fullscreen.

5. Press the UP arrow again. The window will exit fullscreen mode.

6. Now move the mouse outside the animation window. You'll see that the label on the top will remain "INSIDE", which means it has missed the 'mouseleave' event.

After you'll re-enter the mouse, it will catch the next mouseleave event, but for my complex web application it takes several minutes before it finally re-enables mouseleave or mouseout events.
So this test above just exposes the bug partially, but I guess it might be enough for the Pale Moon devs to figure out the issue.

7. Try the same on Firefox, Chrome, Opera. The events will always work properly.

[Tomaso]

For what it's worth, I can confirm the issue in Pale Moon.
SeaMonkey isn't affected by it either.

[New Tobin Paradigm]

How about trying another Phoenix-based browser like both Basilisk and Firefox esr52 and going down the esr line to to major version level to know if it is application level or platform level and when a change occurred.

You know, something useful besides "it works with latest X", Tomaso. Cause that is almost completely useless information.

[Tomaso]

How about trying another Phoenix-based browser like both Basilisk and Firefox esr52 and going down the esr line to to major version level to know if it is application level or platform level and when a change occurred

I already did that, before posting.
Using Mozregrezzion, I went all the way back to 51.0a1 (2016-08-26), which seems to be the first FF version that supports the test.
Of all the builds that I tested, none of them were affected by the bug.
So, it might be a Pale Moon specific issue.

[New Tobin Paradigm]

Okay, is Basilisk affected?

[Tomaso]

Yes .

[New Tobin Paradigm]

If Basilisk is affected.. and the change happened before UXP's fork off.. Then what could have happened...

We need an absolute regression range on this. Paging Dr. Justoff, you know what we need to know.. Please find out.

[JustOff]

In my work environment, the problem described in the starting post is observed everywhere in Pale Moon, Basilisk, Firefox 66.0.2, ESR 60.6.1, ESR 52.9.0, 51.0a1 (2016-08-26) and 68.0a1 (2019-03-31), so there is nothing to test mozregression with

[New Tobin Paradigm]

So Tomaso just wasted everyone's time.. AGAIN. Well.. shit..

[Tomaso]

I just retested this, and came to the same conclusion as before.
If JustOff can't replicate the issue, then perhaps H/W differences plays a part?

[therube]

If I'm doing it correctly...
Not sure I'm particularly seeing any difference between browsers?

Pointer position seems to play into it - (where pointer is positioned) when exiting fullscreen.
(And I'd expect, the browser, overall, rendering efficiency, & a user's graphics.)


If pointer is dead center, say 875x610 (on my end)
when you exit FS, pointer is still within the "blob"
When you then go OUTSIDE, that is not registered until you then come back INSIDE.


If pointer is lower right, 1800x1000
when you exit FS, pointer is outside the sphere of the "blob" (but still INSIDE)
When you then go OUTSIDE (still bypassing the sphere of the blob), OUTSIDE is registered - mostly.
This is most apparent with FF 66.
Sometimes you can get OUTSIDE to register in PM. This is harder to accomplish in PM compared to FF 66.
SeaMonkey (2.49 or 2.53) didn't seem to pass muster here.


If pointer is more left of center, say 350x610
when you exit FS, pointer is already OUTSIDE
In this case, mouseleave is not registered at all, until you first go back INSIDE again.



(Win7 i5-3570k, Intel HD-4000 graphics)

[Tomaso]

when you exit FS, pointer is still within the "blob"
When you then go OUTSIDE, that is not registered until you then come back INSIDE.

This describes the issue perfectly.
It is exactly what the OP reported, and what I'm able to reproduce!

--

If pointer is lower right...

This doesn't matter at my end.
As long as the pointer is anywhere inside of the black sphere window, I get the same result.

--

SeaMonkey (2.49 or 2.53) didn't seem to pass muster here.

I just updated to SeaMonkey v2.49.4, and I can confirm that it doesn't pass the test either.
However, when returning from fullscreen (with the cursor still inside of the sphere window), it shows "OUTSIDE" instead of "INSIDE".
Like with PM, SM also corrects itself when moving the cursor outside and back inside again though.

--

I've been testing this many, many times now, and I'm completely unable to reproduce the issue in Firefox.
In all of the FF builds that I've tried, the test works like excpected, every time.
When returning from fullscreen to normal view, FF briefly shows "OUTSIDE" for a fraction of a second, but then automatically corrects itself.

Chromium-ungoogled also passes the test with flying colours.
Perhaps even better than FF, since it doesn't flash an "OUTSIDE" message at all, which I mentioned that FF does very briefly.

--

I don't know what New Tobin Paradigm's problem is.
Somehow he seems to imply that I'm posting false information or something.
Of course, this is complete nonsense.

[New Tobin Paradigm]

So is this about cursor locking like full screen games can do if you have multi displays where it keeps your cursor inside and if you leave the boundries it takes it back inside?

[Democritus]

So is this about cursor locking like full screen games can do if you have multi displays where it keeps your cursor inside and if you leave the boundries it takes it back inside?

Nope, no cursor locking -this is a bad policy -if the app is crashed it can leave the user without a cursor.

Some use the mouseleave signal to pop-up a message eg trying to convince them do something before they leave the website, making them an offer etc.

I personally use it to replace the mouse with a 3D one in a 3D environment -which is crucial for the proper functioning of the app I'm developing.
When the mouseleave signal is missed, the user sees two mouses, one that has left the window and the 3D one that has stayed at the last position inside the window -at the edge, which looks very sloppy and destroys the website's prestige and definitely it's not something that the user likes to see.

For the dev's convenience, I have uploaded a short unlisted video on YouTube where I show my system and vga info and then I test 5 browsers.
For the bad quality YouTube is solely responsible (for example it doesn't show all resolution options on "newly uploaded videos"...) and that is the first video on that account.
The stuttering is due to the inadequate ram, the old CPU and the 5 browsers running WEBGL along with the software capturing the screen.

I changed the jsfiddle.net's theme to light in order to make the app window more visible.
Since I can't edit the original post, here it is: https://www.youtube.com/watch?v=JaaxYuihcX8

[JustOff]

In my work environment, the problem described in the starting post is observed everywhere in Pale Moon, Basilisk, Firefox 66.0.2, ESR 60.6.1, ESR 52.9.0, 51.0a1 (2016-08-26) and 68.0a1 (2019-03-31)

Here is my screencast made using Firefox 66.0.2, so you can't be sure that your app will work properly with anything other than Chrome.

[Tomaso]

Here is my screencast made using Firefox 66.0.2, so you can't be sure that your app will work properly with anything other than Chrome.

OK, so there are definitely some system-dependent differences then.
I just installed, and tested Firefox v66.0.2 under Win8.1Pro,x64..
Both the 32-bit and the 64-bit version passes the test just fine at my end.
Like I described for the FF builds that I tested through Mozregression; when returning from fullscreen to normal view, it briefly shows "OUTSIDE" for a fraction of a second, but then automatically corrects itself to "INSIDE".
When moving the cursor outside of the sphere window (for the first time, after exiting fullscreen), it immediately says "OUTSIDE"!

[Democritus]

In my work environment, the problem described in the starting post is observed everywhere in Pale Moon, Basilisk, Firefox 66.0.2, ESR 60.6.1, ESR 52.9.0, 51.0a1 (2016-08-26) and 68.0a1 (2019-03-31)

Here is my screencast made using Firefox 66.0.2, so you can't be sure that your app will work properly with anything other than Chrome.

What is your hardware and OS?


I just checked with a new system with the following specs:

CPU: AMD Ryzen 5-2600X 6-core 3.60Ghz
RAM: 16GB
VGA: Radeon RX 580 8GB
OS: Win 10 Pro 1809 64bit

Browsers:
Edge
Firefox
Brave
Pale Moon

All browsers passed the test except Pale Moon.