Description: In the "Insert Hyperlink" dialogue, you can't edit the URL field at all. Steps to Reproduce: 1. Select text. 2. Hit Ctrl-K, "Insert Hyperlink" dialogue opens. 3. Try to paste your URL into the URL field. Actual Results: can't paste into URL field, or edit existing URL field contents Expected Results: allow you to paste or edit URL Reproducible: Always User Profile Reset: Yes Additional Info: No workaround that I can find. If I hit ctrl-K on an existing hyperlink, the URL appears correctly in the dialogue box - but can't be edited. Bug also happens when I restart in Safe Mode. "Graphics Output: Use hardware acceleration" is unticked - so I presume it's not using OpenGL. Version: Version: 6.4.0.0.alpha0+ Build ID: eb5283064e60f5f133a0b37adf21651d16e9c2e4 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded Environment: Xubuntu 18.04 amd64 on Lenovo X250 (compiled on, and running on)
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Caolán: noticing https://cgit.freedesktop.org/libreoffice/core/commit/?id=1942182a3d1817bc539229d7fda3af69f7e295b8, thought you might be interested in this one.
I can't reproduce the bug in Windows - either in the official 6.3 beta 2, or in today's daily build: Version: 6.4.0.0.alpha0+ (x64) Build ID: 12748b06cbdefd67725009520e4c27bd82cab60f CPU threads: 1; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-02_13:41:00 Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded downloaded from: https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/2019-07-02_13.41.00/libo-master64~2019-07-02_13.41.00_LibreOfficeDev_6.4.0.0.alpha0_Win_x64.msi The dialogue box works fine in this version. This was testing in Windows 10, running in VirtualBox.
Just pulled from master and rebuilt to very latest on my Linux box - up to change 35f71c648c45769d4cc75f8b422bcdb020916a73 - bug still manifests
*** Bug 126203 has been marked as a duplicate of this bug. ***
Just tried starting LO with: * SAL_USE_VCLPLUGIN=gen - gives VCL: x11 * SAL_USE_VCLPLUGIN=gtk - gives VCL: gtk2 with either of these, the URL field is editable. So there's a workaround, at least.
only GTK3, don't think it's a high priority bug
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=1942182a3d1817bc539229d7fda3af69f7e295b8 author Caolán McNamara <caolanm@redhat.com> 2019-06-23 19:51:15 +0100 committer Caolán McNamara <caolanm@redhat.com> 2019-06-25 13:36:53 +0200 commit 1942182a3d1817bc539229d7fda3af69f7e295b8 (patch) tree 1c7291efb486d4789c580671ef0ea2133251c92c parent 2f00a7c61fff9c091f08b6aaa4f829cd34fb3745 (diff) weld HyperLink Dialog Bisected with: bibisect-linux64-6.4 Adding Cc: to Caolán McNamara
(In reply to David Gerard from comment #6) > Just tried starting LO with: > > * SAL_USE_VCLPLUGIN=gen - gives VCL: x11 > * SAL_USE_VCLPLUGIN=gtk - gives VCL: gtk2 > > with either of these, the URL field is editable. > > So there's a workaround, at least. Please explain exactly how what the command line has to be to start LO with your solution. Would it be possible to set such an option to some preference file such that it becomes default for every start which does not explicitly ask for something else with respect to VCLPLUGIN? I tired to modify the starter for LibreOfficeWriter in menulibre to this: libreofficedev6.4 --writer SAL_USE_VCLPLUGIN=gtk %U but this did not work for me. I think, such a workaround (if it works) is only a temporary solution. Being able to produce documents which contain hyperlinks is a very basic thing and I use it very frequently and the same applies to all users who use LibreOfficeWriter for purposes beyond composing "a few pages letters" only.
I compile it myself. On this box, my --prefix=/home/fun/bin/libreoffice so I start it from the command line with this command to get gtk2: SAL_USE_VCLPLUGIN=gtk /home/fun/bin/libreoffice/lib/libreoffice/program/soffice
obviously this isn't a *good* workaround, as you note. But it allowed me to continue progress with the complex, link-filled Writer document I was working on :-)
(In reply to David Gerard from comment #10) > I compile it myself. On this box, my --prefix=/home/fun/bin/libreoffice so I > start it from the command line with this command to get gtk2: > > SAL_USE_VCLPLUGIN=gtk > /home/fun/bin/libreoffice/lib/libreoffice/program/soffice David, this is a very valuable finding because it will let someone who really understands those basic functions from gtk, qt and the like direct to really trap the bug. The outcome of this might be "not my bug, it is in gtk". But this would not really eliminate it, because such bugs can trigger more severe results than just not being able to set the URL for a hyperlink! There would not be different versions of gtk unless there are differences between gtk2 and gtk3. Therefore there may be more than one applications affected by the bug. Let me guess, the possible root cause is probably is one of the following: 1. a calling interface has been changed, e.g. by introducing additional parameters and dealing with variable length calling interfaces is not properly implemented everywhere (going through the steps to edit a hyperlink in this case will lead to the one affected - unfortunately among many others!) or 2. by allowing different ranges for values of parameters. If defensive programming style limited the range of such a parameter before, it has worked before but does not work any longer, after the extended value range is used for different situations and the "limit to what is allowed" strategy has been removed to allow such extended use of existing parameters, but with different values. or 3. calling some function required some preconditions being met which are no longer guaranteed, e.g. 3a. in the old code no distinction was necessary between two different use cases of some code segment which existed in multiple similar instances which have been unified. The user of the old code did not have to care about a preconditions because it has been introduced in the unification those similar instances. Therefore one should look if any preconditions were introduced later (hopefully they are documented!). 3b. because some defensive programming code has been disabled which formerly coerced the precondition to be met by substituting what was missing before. But later someone wanted to speed up things and removed or disabled such "unnecessary stuff" because it was clearly said that the precondition must have been met before calling the function in question. Hopefully coercing the precondition has not been completely removed from the code but can be re-activated by setting proper compilation flags and hopefully they can be reactivated in such a way to eject debugging information that a superfluous safety measure really had to be taken because it was necessary in this case... or 4. some of the other rules in https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html has not been observed Anyway, this bug which may (or may not) "live" in the gtk region of the software, is an interesting one as it might go unnoticed in many use cases and in the worst case it might be used to make malicious use of functions. It should be corrected and reasonable thought should be spent in checking if there are other similar cases which might trigger the same bug.
(In reply to Xisco Faulí from comment #8) > Regression introduced by: > > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=1942182a3d1817bc539229d7fda3af69f7e295b8 > > author Caolán McNamara <caolanm@redhat.com> 2019-06-23 19:51:15 +0100 > committer Caolán McNamara <caolanm@redhat.com> 2019-06-25 13:36:53 +0200 > commit 1942182a3d1817bc539229d7fda3af69f7e295b8 (patch) > tree 1c7291efb486d4789c580671ef0ea2133251c92c > parent 2f00a7c61fff9c091f08b6aaa4f829cd34fb3745 (diff) > weld HyperLink Dialog > > Bisected with: bibisect-linux64-6.4 > > Adding Cc: to Caolán McNamara This bug was not present in Version: 6.1.4.2 Build-ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: gtk2; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group threaded Probably it is the same finding as yours and that of David Gerard from comment #6, as can be conjectured from the keyword "gtk2" in the version description.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/643ea4be9011131ab2bcb81077b5fd5e71abcb17%5E%21 Resolves: tdf#126202 url not sensitive, so not editable It will be available in 6.4.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.
Works for me now - in gtk3, hitting ctrl-K on a link brings up the dialogue box with the URL highlighted, which is exactly what I want. Thanks!
just for the record, this bug is 'master' only so no need for backporting
Verified in Version: 6.4.0.0.alpha0+ Build ID: 47a774fbef8c224e4853de3fdd0230b9442bb716 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Caolán, thanks for fixing this issue!
Possibly related: bug 126448 - accessibility issues in new "Hyperlink" dialogue box, but only under GTK3 and not GTK2.
I also wanted to test it, but still today the latest package available at https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF/current/ is of 2019-07-11. Where can I download the current package?
After some time of interruption the website https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF/current/ today provided me with the version Version: 6.4.0.0.alpha0+ Build-ID: 9ee5ad5a0b84bfa652da34694ba4f75668f06087 CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-07-30_13:21:44 Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded I tried this one and now I was able to paste an URL in the Insert>Hyperlink dialogue. Thanks for fixing this bug.
Well, an experienced writer knows how to handle these bugs and fix them and free them well. The https://www.resumewriterslist.com/ help new writers so they can train them well and get the right writers for their company.
I have recreated the issue by following the steps shared here. I am trying to find a solution that helps in fixing the issue easily. I think there are some other users have suggested solution for the issue. Hope it will be effective. http://www.lovecbdgummies.com/cbd-gummies/cbd-gummies-how-is-it-good-for-health/
This post shares the steps to reproduce the problem of 'insert hyperlink dialogue: can't enter or edit the URL'. The problem and the steps to reproduce it is also shared here. https://paristoursnow.com The expected result and the actual result is also given.