Bug 129126 - Inserting formula between some text in a line incorrectly places it at the start of the line.
Summary: Inserting formula between some text in a line incorrectly places it at the st...
Status: RESOLVED DUPLICATE of bug 130362
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2019-12-01 10:51 UTC by Dennis Francis
Modified: 2020-04-11 04:52 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
helper document to reproduce the issue (8.33 KB, application/vnd.oasis.opendocument.text)
2019-12-01 10:53 UTC, Dennis Francis
Details
bibisect-linux-64-6.5, tail of terminal output (2.34 KB, text/plain)
2019-12-04 23:27 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Francis 2019-12-01 10:51:48 UTC
Description:
Inserting formula in the middle of some text in a line incorrectly places it at the beginning of the line(row). Before this regression, the formula used to be placed at the cursor position on insert.

Steps to Reproduce:
1. Open the attachment in writer.
2. Place the cursor between < and > in the second line in the page.
3. Insert a formula (Insert > Object > Formula) (the actual formula content does not matter : for example type x^2 in the formula-editor )
4. Click back in the writer document page.

Actual Results:
The formula is placed at the start of the second line.

Expected Results:
The formula should have been placed between < and > in the second line.


Reproducible: Always


User Profile Reset: No



Additional Info:
This is a regression, it used to work correctly in previous releases.

My master branch's HEAD is ae9e1569e736ad63bf2a2e197441657283c3f344

Version: 6.5.0.0.alpha0+
Build ID: ae9e1569e736ad63bf2a2e197441657283c3f344
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 Dennis Francis 2019-12-01 10:53:01 UTC
Created attachment 156218 [details]
helper document to reproduce the issue
Comment 2 Dieter 2019-12-02 07:07:48 UTC
I can't confirm with

Version: 6.4.0.0.beta1 (x64)
Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: threaded
Comment 3 Dennis Francis 2019-12-02 07:10:51 UTC
Try using a daily build of master branch : https://dev-builds.libreoffice.org/daily/master/
Comment 4 Timur 2019-12-04 10:00:57 UTC
Repro 6.5+ in Windows. New.
Comment 5 Terrence Enger 2019-12-04 23:27:19 UTC
Created attachment 156317 [details]
bibisect-linux-64-6.5, tail of terminal output

Working on debian-buster in bibisect-linus-64-6.5, I see:

          commit    s-h       seq     date
          --------  --------  ------  -------------------
    good  8410d885  83edee30  516511  2019-11-18 16:36:04
    bad   135aa137  a7528cd6  516513  2019-11-18 16:37:13

The bad commit is (lines rewrapped) :

    commit a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db
    Author: Miklos Vajna <vmiklos@collabora.com>
    Date:   Mon Nov 18 13:50:32 2019 +0100

        sw: insert image: set anchor to at-char by default
    
        This changes the default set in commit
        4f40bf6a79de6d60da0a5090cdfeda6242e889f0 (sw: insert image: set anchor
        to as-char by default, 2019-07-04), to have a better compromise,
        taking both Word defaults compatibility and usability into account.
    
        The problem is that users are used to just inserting an image and
        being able to drag it to its final location, which is broken with
        as-char anchoring.
    
        So default to at-char anchoring, this is still something that is fully
        interoperable to Word (unlike the old to-para anchoring), but allows
        the easier image move again.
    
        Change-Id: Ibc61ae167fc9e5cc31b04c83e854556309e27fd4
        Reviewed-on: https://gerrit.libreoffice.org/83089
        Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
        Tested-by: Jenkins

I am removing keyword bibisectRequest and adding keywords bibisected,
bisected.
Comment 6 Dieter 2019-12-05 07:18:38 UTC
cc: Miklos Vajna
Comment 7 Aron Budea 2020-04-11 04:52:54 UTC
Fortunately this is now fixed under bug 130362.

*** This bug has been marked as a duplicate of bug 130362 ***