Created attachment 192372 [details] Screen grab of document being edited, with drag handles on the last page I am documenting a project and putting code samples in a frame. If that results in a frame so large that it overlaps the header and footer I cannot resize it. I have reproduced the same problem with a graphical image pasted in from the draw module. The resize drag handles appear on the object, and the cursor change shape to indicate that they can be dragged, but no amount of dragging will change the size. It is almost as though the heder and footer are laid over the drag handles, and allow them to be selected but not acted upon. The screen grab shows the graphic referred to which, when pasted in, is so large that it overlaps (underlaps???) the footer and header. The cursor has been placed on the bottom right drag handle, and the cursor changed shape, but could not be used to resize the image.
Please attach a sample file, reduce the size as much as possible without private information, and paste the information in Menu/Help/About LibreOffice, there is a copy icon.
Created attachment 192607 [details] document extract as qequested document as requrested. The orange box is a frame, and the bottom dragging edges don't do anything The version number, as requested is Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 24; OS: Windows 10.0 Build 23620; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded
This is very similar to 159728, although it refers to more than just images.
Select the frame, right-click on the border, select properties, on Position & Size tab, disable 'Autosize option'
(In reply to m_a_riosv from comment #4) > Select the frame, > right-click on the border, > select properties, > on Position & Size tab, disable 'Autosize option' Thanks, let's close.
Woah, just a minute. That's not "invalid". That's a hidden solution. Where in the user interface is that exposed? where in the help pages does it tell you to do that if you can't drag the handles? How the blue blistering blazes is someone supposed to guess they can do that? What about making it a bit more obvious what the problem is?
I see the issue. What needs to happen IMO, is to enable inserted object manipulation by default no matter what the user may have as LO settings for such an insertion. This way, the immediate urge to "put things right" is possible. My trial with manipulation via its properties especially `wrap` yielded some headway. I would also add the following as a feature request: * Change the frame window title from `Frame` to `Frame properties`
(In reply to Bogaboga Man from comment #7) > I see the issue. What needs to happen IMO, is to enable inserted object > manipulation by default no matter what the user may have as LO settings for > such an insertion. This way, the immediate urge to "put things right" is > possible. > > My trial with manipulation via its properties especially `wrap` yielded some > headway. I would also add the following as a feature request: > > * Change the frame window title from `Frame` to `Frame properties` It isn't, of course, just an issue with frames...
Essentially you expect the frame to behave like a scrolled window - if the content exceeds the size a scrollbar appear. I disagree with this idea. While shrinking the height you get feedback but it's just not accepted below the content height. Very common interaction, IMO.
I just expect the drag handles to work if the cursor knows they are there and changes shape to suggest they should. That's all I expect. And if some weird interaction with the footer means they can't, then the drag handles should not be displayed in the first place. (or perhaps in red to denote they don't work???)
(In reply to m_a_riosv from comment #4) > on Position & Size tab, disable 'Autosize option' (In reply to Bob Harvey from comment #6) > What about making it a bit more obvious what the problem is? STR: * on a new document, insert a frame which is should be not too wide * add some text like lorem+f3 => frame is sized to the max page height Possible solutions: a) accept as common interaction b) consider as bug since SE/NW etc. resize does not shrink the frame c) don't enable autosize by default to make user aware of it d) block resizing on the autosized dimension (not sure that can be done)
*** Bug 159728 has been marked as a duplicate of this bug. ***
Maybe, the 3rd solution is the better one : don't enable autosize by default to make user aware of it. Give more freedom and flexibility...
(In reply to Bob Harvey from comment #6) > Woah, just a minute. > > That's not "invalid". That's a hidden solution. Where in the user > interface is that exposed? where in the help pages does it tell you to do > that if you can't drag the handles? How the blue blistering blazes is > someone supposed to guess they can do that? Basically one needs an expert at the desk to help with any question ;) (In reply to Bob Harvey from comment #10) > I just expect the drag handles to work if the cursor knows they are there > and changes shape to suggest they should. That's all I expect. Changing the handles is further dragging is blocked, looks a nice improvement to me.
We discussed the topic in the design meeting. It likely feels wrong to block the vertical sizing and/or to hide the handles. We also rejected the idea to show an infobar on drop when the resizing is rejected internally (although it might be easy to implement). The best solution is to give a proper feedback during the resizing, which could be a red frame when the new size is not accepted. That depends on the height and width and means to recalculate on-the-fly.
While all that it said above is sound, I'd like point out that bug 159728, which is at the moment is marked as duplicate of this one, is about a different scenario: a picture pasted into Write becomes unresizeable immediately after pasting without additional resizing, so the 'reject improper resize' approach won't help there because the initial size of the pasted image is selected incorrectly. Should we reopen bug 159728 or consider the initial pasting size and/or location within the scope of this bug?
(In reply to Heiko Tietze from comment #15) > We discussed the topic in the design meeting. > > It likely feels wrong to block the vertical sizing and/or to hide the > handles. We also rejected the idea to show an infobar on drop when the > resizing is rejected internally (although it might be easy to implement). > The best solution is to give a proper feedback during the resizing, which > could be a red frame when the new size is not accepted. That depends on the > height and width and means to recalculate on-the-fly. OK. So long as the red frame is mentioned in the documentation, of course!
Sahil Gautam committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/86cd6036273a9031212e131141c03ed4e16e011b tdf#159543 - Proper feedback needed when resizing a frame... It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.