Open Bug 1105906 Opened 8 years ago Updated 4 months ago
Cursor moves away from resizer of centered textarea
STR: 1. Open the following page: data:text/html,<center><textarea></textarea> 2. Resize the textarea towards, stretching it to the bottom right ER: The cursor should stay positioned above the textarea resizer AR: The cursor moves 2x the distance away from the resizer
Component: Preferences → Widget
Product: Firefox → Core
Hi, (It's my first time on firefox code) so I don't know if it's the good bug to start. the problem is in the movement in the X axis and it work fine for Y axis. I saw that we don't have any problem with data:text/html,<textarea></textarea> so i'm thinking that maybe there is different implementation for resizerRect but I didn't found it ! Can you please tell me more about it or guide me? Chaasof
This is probably not a good first bug to work on, as it may involve various parts of the codebase and needs to regress other behavior. Neil, do you know who might be able to help here?
The resizer works by changing the width and height of the element that it is resizing. In this case, the size is changing correctly, but the textarea is centered so its position moves by the corresponding amount as well, causing its right edge to only move half the width that the mouse moves. You would need to be able to detect whether this situation was going to happen and resize only half the size.
Thanks. We could probably fix this by adjusting the code in nsResizerFrame.cpp at http://mxr.mozilla.org/mozilla-central/source/layout/xul/nsResizerFrame.cpp?rev=4a65cacf8a37#195 to halve the width if the element is "anchored" in the horizontal center. Determining if an element is horizontally centered isn't obvious to me though, as an element can become centered through various ways: <center>, text-align:center; on a parent element, margin-left:auto,margin-right:auto,display:block; on itself, etc. Webkit handles this the right way, so we may be able to see how they have tackled the problem.
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #4) > Thanks. We could probably fix this by adjusting the code in > nsResizerFrame.cpp at > http://mxr.mozilla.org/mozilla-central/source/layout/xul/nsResizerFrame. > cpp?rev=4a65cacf8a37#195 to halve the width if the element is "anchored" in > the horizontal center. > > Determining if an element is horizontally centered isn't obvious to me > though, as an element can become centered through various ways: <center>, > text-align:center; on a parent element, > margin-left:auto,margin-right:auto,display:block; on itself, etc. > > Webkit handles this the right way, so we may be able to see how they have > tackled the problem. We could use the element offset I guess. Instead of rect.width, we'll have : rect.width * (rect.offsetX / document.width) or something similar. Though I'm not sure we have all that info in the C++ code.
That may work for this simple example, but won't work for an element that is centered within an offset element.
if we can have some informations about the container of the element like : container.x and container.width, we can determine the center with (container.width - container.x)/2 and the same for the element : (element.width - element.x) / 2 => element.offsetX = mouseMove.offsetX * 2
Webkit also fails to recalculate when the CSS width:fit-content and resize:vertical are applied to an element, see https://bugs.webkit.org/attachment.cgi?id=228078 In that case it's fine for the cursor to move away from the resizer, and gecko gets it right so we don't want to regress that.
> You would need to be able to detect whether this situation was going to > happen and resize only half the size. Of course, I meant to say that you would need to double the size, not half the size.
You need to log in before you can comment on or make changes to this bug.