Bugzilla

Thank you for your testing!

(In reply to Q from comment #27)
> I feel like this time firefox is recognize the tablet as touch instead of as mouse like in version 140.

I don't understand well, though. Gecko handles pen input as "pen". However, yes, it's similar to touch while your pen touches the tablet/digitizer. On the other hand, the pen doesn't touch the tablet/digitizer but hovers over that, it's handled like a mouse.

"pen" is always managed as a pen, not a mouse because it has a specific `pointerId` at least until it leaves from the tablet/digitizer.

Previously, we managed pointer events' boundary state only for the last active one, but started for preceding ones too. Therefore, if there are a lot of active pointers, the performance after a layout change or a scroll may get worse. However, it basically not happen, in the worst case, there could be a couple of pens and mouse. On the other hand, if Gecko fails to manage pointers ledt from active document, there could be a lot of zombie pointers and make the damege to the performance.

> Right now, I don't see any flickering, 

Thanks, the second patch tries to ignore the odd native mouse move messages coming from OS. They caused the flicker since mouse is moved between the last pen position and the last mouse position continuously.

> but if I hover my pen on a hyperlink and then lift the pen, the hyperlink is defocused and the URL at the bottom of the window doesn't show anymore.

Good point... I think it's expected behavior from the code written for mouse point of view. Although we could make the behavior better for pen users.

> One behavior that improved for me is that when I switch to telegram tab, I can paste stuff into the chat right away without having to tap once within the chat area first. That behavior was broken for me in version 141.

I think it's not related. The test builds are based on yesterday's nightly build, i.e., alpha of 143. So, various othe fixes are included.


I'd like to get more feedback from a couple of other users too before requesting review...

Thank you for your testing!

(In reply to Q from comment #27)
> I feel like this time firefox is recognize the tablet as touch instead of as mouse like in version 140.

I don't understand well, though. Gecko handles pen input as "pen". However, yes, it's similar to touch while your pen touches the tablet/digitizer. On the other hand, the pen doesn't touch the tablet/digitizer but hovers over that, it's handled like a mouse.

"pen" is always managed as a pen, not a mouse because it has a specific `pointerId` at least until it leaves from the tablet/digitizer.

Previously, we managed pointer events' boundary state only for the last active one, but started for preceding ones too. Therefore, if there are a lot of active pointers, the performance after a layout change or a scroll may get worse. However, it basically not happen, in the worst case, there could be a couple of pens and mouse. On the other hand, if Gecko fails to manage pointers left from active document, there could be a lot of zombie pointers and make the damege to the performance.

> Right now, I don't see any flickering, 

Thanks, the second patch tries to ignore the odd native mouse move messages coming from OS. They caused the flicker since mouse is moved between the last pen position and the last mouse position continuously.

> but if I hover my pen on a hyperlink and then lift the pen, the hyperlink is defocused and the URL at the bottom of the window doesn't show anymore.

Good point... I think it's expected behavior from the code written for mouse point of view. Although we could make the behavior better for pen users.

> One behavior that improved for me is that when I switch to telegram tab, I can paste stuff into the chat right away without having to tap once within the chat area first. That behavior was broken for me in version 141.

I think it's not related. The test builds are based on yesterday's nightly build, i.e., alpha of 143. So, various othe fixes are included.


I'd like to get more feedback from a couple of other users too before requesting review...

Thank you for your testing!

(In reply to Q from comment #27)
> I feel like this time firefox is recognize the tablet as touch instead of as mouse like in version 140.

I don't understand well, though. Gecko handles pen input as "pen". However, yes, it's similar to touch while your pen touches the tablet/digitizer. On the other hand, the pen doesn't touch the tablet/digitizer but hovers over that, it's handled like a mouse.

"pen" is always managed as a pen, not a mouse because it has a specific `pointerId` at least until it leaves from the tablet/digitizer.

Previously, we managed pointer events' boundary state only for the last active one, but started for preceding ones too. Therefore, if there are a lot of active pointers, the performance after a layout change or a scroll may get worse. However, it basically not happen, in the worst case, there could be a couple of pens and mouse. On the other hand, if Gecko fails to manage pointers left from active document, there could be a lot of zombie pointers and make the damege to the performance.

> Right now, I don't see any flickering, 

Thanks, the second patch tries to ignore the odd native mouse move messages coming from OS. They caused the flicker since the last active pointer is continuously switched between the last used pen and the mouse and that caused hovering position is continuously changed between them. Therefore, even if the cursor is not changed, CPU power is wasted to consider which content is under the last active pointer again and again.

> but if I hover my pen on a hyperlink and then lift the pen, the hyperlink is defocused and the URL at the bottom of the window doesn't show anymore.

Good point... I think it's expected behavior from the code written for mouse point of view. Although we could make the behavior better for pen users.

> One behavior that improved for me is that when I switch to telegram tab, I can paste stuff into the chat right away without having to tap once within the chat area first. That behavior was broken for me in version 141.

I think it's not related. The test builds are based on yesterday's nightly build, i.e., alpha of 143. So, various othe fixes are included.


I'd like to get more feedback from a couple of other users too before requesting review...

Thank you for your testing!

(In reply to Q from comment #27)
> I feel like this time firefox is recognize the tablet as touch instead of as mouse like in version 140.

I don't understand well, though. Gecko handles pen input as "pen". However, yes, it's similar to touch while your pen touches the tablet/digitizer. On the other hand, the pen doesn't touch the tablet/digitizer but hovers over that, it's handled like a mouse.

"pen" is always managed as a pen, not a mouse because it has a specific `pointerId` at least until it leaves from the tablet/digitizer.

Previously, we managed pointer events' boundary state only for the last active one, but started for preceding ones too. Therefore, if there are a lot of active pointers, the performance after a layout change or a scroll may get worse. However, it basically not happen, even in the realistic worst case, there could be a couple of pens and mouse at most. On the other hand, if Gecko fails to manage pointers left from active document, there could be a lot of zombie pointers and make the damege to the performance.

> Right now, I don't see any flickering, 

Thanks, the second patch tries to ignore the odd native mouse move messages coming from OS. They caused the flicker since the last active pointer is continuously switched between the last used pen and the mouse and that caused hovering position is continuously changed between them. Therefore, even if the cursor is not changed, CPU power is wasted to consider which content is under the last active pointer again and again.

> but if I hover my pen on a hyperlink and then lift the pen, the hyperlink is defocused and the URL at the bottom of the window doesn't show anymore.

Good point... I think it's expected behavior from the code written for mouse point of view. Although we could make the behavior better for pen users.

> One behavior that improved for me is that when I switch to telegram tab, I can paste stuff into the chat right away without having to tap once within the chat area first. That behavior was broken for me in version 141.

I think it's not related. The test builds are based on yesterday's nightly build, i.e., alpha of 143. So, various other fixes are also included.


I'd like to get more feedback from a couple of other users too before requesting review...

Thank you for your testing!

(In reply to Q from comment #27)
> I feel like this time firefox is recognize the tablet as touch instead of as mouse like in version 140.

I don't understand well, though. Gecko handles pen input as "pen". However, yes, it's similar to touch while your pen touches the tablet/digitizer. On the other hand, the pen doesn't touch the tablet/digitizer but hovers over that, it's handled like a mouse.

"pen" is always managed as a pen, not a mouse because it has a specific `pointerId` at least until it leaves from the tablet/digitizer.

Previously, we managed pointer events' boundary state only for the last active one, but started for preceding ones too. Therefore, if there are a lot of active pointers, the performance after a layout change or a scroll may get worse. However, it basically not happen, even in the realistic worst case, there could be a couple of pens and mouse at most. On the other hand, if Gecko fails to manage pointers left from active document, there could be a lot of zombie pointers and make the damege to the performance.

> Right now, I don't see any flickering, 

Thanks, the second patch tries to ignore the odd native mouse move messages coming from OS. They caused the flicker since the last active pointer is continuously switched between the last used pen and the mouse, and that caused hovering position is continuously changed between their last positions. Therefore, even if the cursor is not changed, CPU power is wasted to consider which content is under the last active pointer again and again.

> but if I hover my pen on a hyperlink and then lift the pen, the hyperlink is defocused and the URL at the bottom of the window doesn't show anymore.

Good point... I think it's expected behavior from the code written for mouse point of view. Although we could make the behavior better for pen users.

> One behavior that improved for me is that when I switch to telegram tab, I can paste stuff into the chat right away without having to tap once within the chat area first. That behavior was broken for me in version 141.

I think it's not related. The test builds are based on yesterday's nightly build, i.e., alpha of 143. So, various other fixes are also included.


I'd like to get more feedback from a couple of other users too before requesting review...