Apache OpenOffice (AOO) Bugzilla – Issue 124210
WRITER - Table (top row border) cannot be "resized upwards".
Last modified: 2014-02-17 16:21:17 UTC
Steps: Make a table and try resizing each outer edge: Bottom Right Left Observe that you can resize them. Now select the top edge of the table. It can not be resized. Expected: It should behave like the Bottom, Right and Left edges.
I notice that it is actually also not possible to resize the bottom edge of the table downwards.
Created attachment 82552 [details] Sample Document Reproducible with server installation of "AOO 4.1.0-Dev – English UI / German locale - [AOO410m1(Build:9750) - Rev. 1565724 - 2014-02-09]" on German WIN7 Home Premium (64bit)", own separate user profile. But I am not 100% sure whether I observe the same problem as reporter steps how to reproduce: 0. Open attached Sample Document 1. Click behind heading “Example and test area” > Caret flashes behind heading 2. Move mouse pointer to cell border below Cell A1 unitl Tooltip “Adjust Table Row” appears and mouse pointer view changes 3. Click horizontal border and drag and drop ½ rowh height down Expected: increases row height of Row 1 Actual: Nothing :-( 4. Click into Cell A1 5. Move mouse pointer to cell border below Cell A1 unitl Tooltip “Adjust Table Row” appears and mouse pointer view changes 6. Click horizontal border and drag and drop ½ rowh height down > now it works as expected
Additional Info: (a) Already Reproducible with * server installation of "AOO 3.4.0 – German UI / German locale [AOO340m1(Build:9590) - Rev.1327774]" on German WIN7 Home Premium (64bit)", own separate user profile * server installation of "Ooo 3.1.1 German WIN7 Home Premium (64bit) DE [OOO310m19 (Build 9420)]" * server installation of "OOo 2.0.2 [680m5 (Build 9011)]" German WIN7 Home Premium (64bit) (b) Was still ok with * No Version (1.1.5 had no option to resize row height using mouse(?)) (c) difficult to believe that this old issue has not yet been reported. @Sam Jennings: Do I describe the problem you observed?
(d) There might be relations to "Bug 95148 - cannot resize table rows" (e) Still a problem with LibO 4.1.3
(In reply to Sam Jennings from comment #1) > I notice that it is actually also not possible to resize the bottom edge of > the table downwards. The bottom behavior is intermittent. Sometimes it does not resize, sometimes it does. I'm not sure what the difference is but I think your description applies to that one, Rainer. The more I study it, I think that should be filed as a separate bug. It is inherently different, but it is still a bug.
> @Sam Jennings: > Do I describe the problem you observed? In fact I'm sure this is two bugs. In the case I describe here, the mouse cursor never changes. That is specifically for the top edge of the top cell of the top row... or more easily described as the top edge of the table. In this case, the tooltip turns to a down-arrow, and the user is never given the chance to resize the top edge. If the user tries, the table column is selected, instead of changing cursor to a resize/boundary moving cursor.
(In reply to Sam Jennings from comment #6) > > @Sam Jennings: > > Do I describe the problem you observed? > > In fact I'm sure this is two bugs. In the case I describe here, the mouse > cursor never changes. That is specifically for the top edge of the top cell > of the top row... or more easily described as the top edge of the table. In > this case, the tooltip turns to a down-arrow, and the user is never given > the chance to resize the top edge. If the user tries, the table column is > selected, instead of changing cursor to a resize/boundary moving cursor. Sorry, that's not the "tooltip" which doesn't change, it's the mouse cursor... and it actually does change, but it changes to the wrong mouse cursor.
Rainer just requested that I make sure the differences between these two bugs are completely clarified, and I agree that's needed. I originally thought these were the same bug, but they are very clearly different ones with a similar end result. Bug 1 (This bug) In the first case, the mouse cursor does not change to a "table/row edge moving cursor" when it is dragged over the top-most edge of the table. Instead, it changes to a "down arrow". If the user clicks the edge with that down arrow it does not allow the user to move the top edge of the table. It only selects the row, beneath. That is different behavior from any other edge of the table. I'm not aware of any workaround for this bug. Bug 2 (Rainer's bug) In the second case, a completely separate bug, if the mouse cursor is not in a table cell, and the user tries to move any horizontal table border up or down (by moving the mouse cursor over it, clicking down, dragging the mouse, and then releasing the mouse button), the border does not move. This does not happen with vertical borders... only horizontal ones. The workaround is to put the mouse cursor into the table. After the user does that, horizontal borders can be moved freely.
Comment 8 unrelated to problem described in summary @Sam Jennings: In private mail I asked you to submit a new Bug report for any other problem than the one currently described in summary line. Any unrelated comments in a Bug report only slow down bug fixing process. BTW your "Bug 1 (This bug)" is "NOT_AN_ISSUE", if you think more discussion is required please also submit a new bug report for that problem!
(In reply to Rainer Bielefeld from comment #9) > Comment 8 unrelated to problem described in summary > > @Sam Jennings: > In private mail I asked you to submit a new Bug report for any other problem > than the one currently described in summary line. Any unrelated comments in > a Bug report only slow down bug fixing process. BTW your "Bug 1 (This bug)" > is "NOT_AN_ISSUE", if you think more discussion is required please also > submit a new bug report for that problem! I get the sense you have never tried to use an openoffice table for anything other than testing. In practice 124210 is a real pain, and is definitely a bug. Behavior for top edge is not the same as it is for bottom, right and left. Moreover, there is no reasonable workaround. The only alternative is to resize each row beneath the top row, all the way down to the base of the graph...which frankly is utterly inane. If you don't believe that, try making a table 20 row table, and format each row exactly the size you want. Now try to resize the top cell. Get back here and report how long it took you to make it look the way you wanted... all because someone refused to fix a bug. The other bug is your find.
I think the best way to clarify this for Rainer and any other naysayers is to say this: Pick any row in the table other than the very top. Move its top border. Note that you are able to do so. Now try to move the top border of the top row. It is NOT possible. This characteristic makes for a very bad user experience when the user needs to resize the top row. That's because the only workaround is to resize every single bottom edge beneath it. In larger, heavily-formatted, tables this is painfully impossible. The problem is compounded by the fact that you can only move a table or cell border by clicking a 1 pixel location. (see bug 124236 for details)
@Sam, *, (In reply to Sam Jennings from comment #0) > > Now select the top edge of the table. It can not be resized. > > Expected: > It should behave like the Bottom, Right and Left edges. Why? Rather, inability to select and adjust the fixed position is a 'feature' of how the tables are built as sw vcl structures. Specifically, the table is anchored. And relative to that anchor, the top edge placement CAN be adjusted (for the current table) from the Table --> Table Properties --> Table tab Spacing '~Above' spinner And, keeping in mind that it is anchored, the height of the first row CAN be adjusted simply using mouse 'adjust table row' click and drag of its bottom edge, or by selecting the entire row and applying its height from its context menu --> Row --> Height. Heights of the rows below are unaffected with this menu based resize. Because it would involve adjustments relative to the anchor, a mouse GUI based movement of the top edge and accompanying row resize would be more complicated than setting the other edges. It simply is not implemented. Given correct behavior of the top edge, and work around(s) I list, setting this as a potential UX enhancement--and reverting title.
(In reply to Sam Jennings from comment #8) > Bug 2 (Rainer's bug) > In the second case, a completely separate bug, if the mouse cursor is not in > a table cell, and the user tries to move any horizontal table border up or > down (by moving the mouse cursor over it, clicking down, dragging the mouse, > and then releasing the mouse button), the border does not move. This does > not happen with vertical borders... only horizontal ones. The workaround is > to put the mouse cursor into the table. After the user does that, > horizontal borders can be moved freely. This also is correct behavior. Tables are discrete objects within a Writer document. The object must gain program focus (by placement of the text cursor into the table) before the table object can be modified. Simply passing the mouse over the table does not move program focus into the object--nor should it.
*** Issue 124237 has been marked as a duplicate of this issue. ***
I share Sam's view and see this as a bug. But more a bug in the feature design than in its implementation. Compare the resize behavior to that of an image. The image can be resized in all four directions (and also all four diagonals). The main difference is that the image has a visible anchor (with little anchor icon and all). Resizing by moving its top edge moves the anchor to a different locations. In contrast the table has a fixed position in the text. You can modify its size but not its location. Having said all this, I have no idea of how to make this better. The table is part of the text flow, ie you can move the cursor into it like with any other text portion. That same is not possible with images. So, what would be the expected behavior of resizing a table via its top edge?
(In reply to Sam Jennings from comment #8) > Rainer just requested that I make sure the differences between these two > bugs are completely clarified, and I agree that's needed. I originally > thought these were the same bug, but they are very clearly different ones > with a similar end result. > > Bug 1 (This bug) > In the first case, the mouse cursor does not change to a "table/row edge > moving cursor" when it is dragged over the top-most edge of the table. > Instead, it changes to a "down arrow". If the user clicks the edge with > that down arrow it does not allow the user to move the top edge of the > table. It only selects the row, beneath. That is different behavior from > any other edge of the table. I'm not aware of any workaround for this bug. > It is intended behavior for the top edge of a table - this is the 'column select feature via mouse' > Bug 2 (Rainer's bug) > In the second case, a completely separate bug, if the mouse cursor is not in > a table cell, and the user tries to move any horizontal table border up or > down (by moving the mouse cursor over it, clicking down, dragging the mouse, > and then releasing the mouse button), the border does not move. This does > not happen with vertical borders... only horizontal ones. The workaround is > to put the mouse cursor into the table. After the user does that, > horizontal borders can be moved freely. I can reproduce this one and I agree it is a defect.
(In reply to Sam Jennings from comment #11) > I think the best way to clarify this for Rainer and any other naysayers is > to say this: > > Pick any row in the table other than the very top. Move its top border. > Note that you are able to do so. Now try to move the top border of the top > row. It is NOT possible. This characteristic makes for a very bad user > experience when the user needs to resize the top row. That's because the > only workaround is to resize every single bottom edge beneath it. In > larger, heavily-formatted, tables this is painfully impossible. The problem > is compounded by the fact that you can only move a table or cell border by > clicking a 1 pixel location. (see bug 124236 for details) My observations are the following ones: (A) When I move the top border of row N (N = 2, 3, ...) via the mouse, then the height of row N-1 is changed and all other rows keep their heights. No change to the height of row N. (B) Moving of the top border of row 1 via the mouse is not possible. Instead I got the 'column selection feature'. (C) I have inserted a table with 20 rows and gave each row its own height. To change the height of row 1 I moved just the bottom border of row 1. All other rows keep their heights. --> I did not observe any bad user experience on changing the height of row 1 @Sam Jennings: - Can you reproduce my observations? - Did you observe a change of the height of row N, when you move its top border via the mouse?
(In reply to Andre from comment #15) In PM Rainier pointed out the more ambitious rework enhancement of bug 6540 -- Freely move, position and anchor table(s) like Frame objects. My thought for this is a less ambitious goal of ONLY implementing the mouse GUI movement & sizing spacing of the top edge of a Table relative to its default anchor. No new function--just adding GUI to set "spacing above".
> @Sam Jennings: > - Can you reproduce my observations? > - Did you observe a change of the height of row N, when you move its top > border via the mouse? Yes, I can. No row resize beneath. That reduces urgency, because on a practical level, there is a workaround. I still believe this is a bug in terms of "ease of flow" and "intuitive usability". In the context which is provided, column selection is an intuitively unexpected feature which deviates from all other table edges, and it's very easy to select a column without it.
> So, what would be the expected behavior of resizing a table via its top edge? This is not (In reply to V Stuart Foote from comment #13) > (In reply to Sam Jennings from comment #8) > > > Bug 2 (Rainer's bug) > > In the second case, a completely separate bug, if the mouse cursor is not in > > a table cell, and the user tries to move any horizontal table border up or > > down (by moving the mouse cursor over it, clicking down, dragging the mouse, > > and then releasing the mouse button), the border does not move. This does > > not happen with vertical borders... only horizontal ones. The workaround is > > to put the mouse cursor into the table. After the user does that, > > horizontal borders can be moved freely. > > This also is correct behavior. Tables are discrete objects within a Writer > document. The object must gain program focus (by placement of the text > cursor into the table) before the table object can be modified. > > Simply passing the mouse over the table does not move program focus into the > object--nor should it. But the user just clicked the table (border) to try to move it. Shouldn't that give it the focus?
@Andre > Having said all this, I have no idea of how to make this better. The table > is part of the text flow, ie you can move the cursor into it like with any > other text portion. That same is not possible with images. So, what would > be the expected behavior of resizing a table via its top edge? I think we should hear all proposals before deciding. These strike me as the main 3 possibilities: (1) Move the top table edge upwards if there are "empty" (eoln only) lines above the table. Don't expand it into text. (2) Move the top table edge upwards, even if there is text there, and "relocate" the text to beneath the table. (3) Move the top table edge "upwards" by expand the table downwards. Do not expand it into any lines or text above. Of course I'd be thrilled to see other ideas here, too.
(In reply to Sam Jennings from comment #21) > @Andre > Of course I'd be thrilled to see other ideas here, too. I just realized I'm only looking at upwards expansion. We need behaviors for "downsizing", as well.
(In reply to Sam Jennings from comment #22) > (In reply to Sam Jennings from comment #21) > > @Andre > > Of course I'd be thrilled to see other ideas here, too. > > I just realized I'm only looking at upwards expansion. We need behaviors > for "downsizing", as well. Whatever the downsizing behavior is, it should be a logical reversal of the upsizing, so the user's last action can be undone by it if he decides to reverse what he just did with an edge move to its previous location. Otherwise the frustration factor could be bad.
For rows we have both row selection and horizontal resize. But you need a steady hand to move the mouse exactly over the left edge. The same could be done for the top edge, i.e. offer both column selection (present) and resize (missing). We "just" have to define the exact behavior of the resize and then implement it. I am not sure if anyone has both the expertise and the time to do that.
@Sam: Looks like you took care of defining the new behavior, all three points are good ideas.
(In reply to Andre from comment #25) > @Sam: Looks like you took care of defining the new behavior, all three > points are good ideas. Thanks! I suspect (1) and (3) are the best candidates, because if resizing upwards can move text beneath the table it's not going to be a reversible action if the user moves the top edge upwards again. The logical reversal of (1) for a downsize is to insert (eoln) blank lines of text. The drawback is a blank line has a fixed size, and the user might want to be more precise than that. On the other hand, the logical reversal of (3) could be a very literal inverse action of upsizing... that being reducing the size of the table and its top row, but moving the bottom table edge upwards.
(In reply to Sam Jennings from comment #26) > (In reply to Andre from comment #25) > > @Sam: Looks like you took care of defining the new behavior, all three > > points are good ideas. > > Thanks! > > I suspect (1) and (3) are the best candidates, because if resizing upwards > can move text beneath the table it's not going to be a reversible action if > the user moves the top edge upwards again. > > The logical reversal of (1) for a downsize is to insert (eoln) blank lines > of text. The drawback is a blank line has a fixed size, and the user might > want to be more precise than that. > > On the other hand, the logical reversal of (3) could be a very literal > inverse action of upsizing... that being reducing the size of the table and > its top row, but moving the bottom table edge upwards. Sorry, correction: > the user moves the top edge upwards again. Should be: "the user moves the top edge downwards again."
(In reply to Sam Jennings from comment #27) > (In reply to Sam Jennings from comment #26) > > (In reply to Andre from comment #25) > > > @Sam: Looks like you took care of defining the new behavior, all three > > > points are good ideas. > > > > Thanks! > > > > I suspect (1) and (3) are the best candidates, because if resizing upwards > > can move text beneath the table it's not going to be a reversible action if > > the user moves the top edge upwards again. > > > > The logical reversal of (1) for a downsize is to insert (eoln) blank lines > > of text. The drawback is a blank line has a fixed size, and the user might > > want to be more precise than that. > > > > On the other hand, the logical reversal of (3) could be a very literal > > inverse action of upsizing... that being reducing the size of the table and > > its top row, but moving the bottom table edge upwards. > > Sorry, correction: > > the user moves the top edge upwards again. > > Should be: > "the user moves the top edge downwards again." No, I had it right the first time. Foot in mouth. I'll stop now. :-)