As an example, I want to link to Nars's answer at https://ask.libreoffice.org/en/questi.... That answer has a link icon to its lower right, at approximately the same vertical position as the start of comments on that answer. The link's URL is https://ask.libreoffice.org/en/questi.... As a sanity check, I confirmed that the link icon for other answers varies only in the tail part of the URL, starting with /?answer=.....

What doesn't make sense is that when I enter the URL into a browser, it goes to the top of the question's page. It doesn't position the browser at the answer. So the link to the answer is no better than a link to the question.

Is there any way to get a link to a specific answer, or is this just buggy behaviour on the server side?

edit retag close merge delete

Good question but I have no answer. Could you, please, change tag common to meta? Use the edit link at end of title, not the one below the question. Thanks.

( 2020-04-12 08:14:20 +0100 )edit

Have you considered that, in order to understand an answer, it is often necessary to first understand the question? So, the question is sometimes a good place to start.

( 2020-04-12 15:33:37 +0100 )edit

I could not confirm the "when I enter the URL into a browser, it goes to the top of the question's page". The has an url of the kind:

https://ask.libreoffice.org/en/question/29139/can-the-new-start-screen-in-v42-be-reverted-to-that-in-v41/?answer=36673#post-id-36673


It has an "answer" GET parameter pointing to which section should be highlighted, and also a fragment starting with # that tells the browser where to scroll (both naturally referring to the same answer). I have confirmed that e.g. Google Chrome shows the accepted answer by @Nars at the top of the window when it opens the URL.

( 2020-04-12 16:03:54 +0100 )edit

@ajlittoz: I was in the process of changing tag common to meta, but a question occurred to me. Hoping you can shed light. I can divine the reason for meta, but am I right in assuming that common means it applies across all of the LibreOffice apps? What distinguishes these two tags?

@ve3oat: I see your point. In general (not necessarily the example here), however, for a thread with many responses, it may be hard to focus a reader on the specific post of interest. So the link icon for each post should yield a URL that directs the browser to the specific post. Otherwise, the icon should not be there.

@Mike Kaganski: Interesting. The # syntax should not be specific to a browser. I've used that notation decades ago. I just tried the URL in Microsoft Edge, and I still get positioned at the top of the page rather ...(more)

( 2020-04-12 19:10:01 +0100 )edit

As I said, # denotes "fragment" URL part that is of course in standard. So of course, it is not browser-specific.

( 2020-04-12 19:44:19 +0100 )edit

Yes, thanks. I understood. My point is that it seems to be that the observed behaviour seems to be browser specific. It works for you on Chrome. It fails for me on Firefox and Edge. Until we get more information, the problem as I see it is that the browser-specific behaviour deviates from the expectation of browser-agnostic and proper positioning of the browser at the specified portion of that page.

( 2020-04-12 22:51:11 +0100 )edit

@JustA.NotherUser: you understand right. common relates to an issue "common" to all components when using LO, e.g. something with print or Tools>Options, features which are shared, or also font rendering or window management. meta is not "directly" related to LO usage; this is why questions about AskLO are tagged so, but you could also have questions about LO "philosophy", workflow , principles or roadmap. These questions do not involve matter-of-fact problems encountered during a precise usage (but may evoke potential problems).

Sometimes the dividing line between common and meta may be thin. But, in no case, common has the usual meaning of "problem-universally-met-by-all-users-in-daily-use". So analyse first your problem. It stems from a concrete issue with a component. When in doubt about the shared nature, choose to tag with the component name (writer, calc, etc.).

( 2020-04-13 07:52:50 +0100 )edit

Sort by » oldest newest most voted

What doesn't make sense is that when I enter the URL into a browser, it goes to the top of the question's page

Not the case for myself. Using the answer-link in the question my browser ends up looking at the (selected) answer (by Nars).

• Chromium Version 83.0.4103.116 (Developer Build) built on Debian 10.4, running on Debian 10.0 (64-bit)

or is this just buggy behaviour on the server side?

Nothing to do with the server, everything to do with the client browser.

I'm going to deconstruct the whole thing because @justanotheruser cannot accept what I am saying.

The link url is deconstructed into it's URL scheme as follows:-

(the text of the question duplicated within the URL can be removed):
(using php parse_url() on that gives):
4. ["scheme"]=>"https"
6. ["path"]=>"/en/question/29139/"
7. ["fragment"]=>"post-id-36673"

When the URI in (3) is issued by a browser, it does the following:-
a) It determines the address of the host using DNS
b) It sends a HTTP GET request to the host composed from parts of the URI in (3)
c) The server will respond with a 301 Moved Permanently pointing to the original URI as in (1)
d) The browser repeats previous actions, now using (1)
e) The file-resource at the path arrives at the browser, possibly in a hundred little pieces, and not necessarily in order
f) The browser consults to see whether it (i) has the file-resource already in it's cache and, if so, (ii) whether that cache can be used
g) The file-resource (either new or as-cached) is shown on-screen; the top of the file is shown at the top of the screen (naturally, only when the browser has both received it & composed it for the screen)
h) When enough of the file-resource has been received as to reach the location of the fragment (and all points in between to the top of the file) then the view can be shifted down to the fragment.

And now, as long as your internet has not lost any vital bits of the file, you should be looking at Nars's answer. If not, then any problem lies with some combination of your machine / browser / internet-connection. If it can work without a problem for me (and it does) then potentially the same can be true for you.

more

Thanks, Alex. I marked your response as helpful, but not the answer because there doesn't seem to be a trick that works across browsers. In fact, the use of the "#" fragment in the URL only works for me on Edge and Chrome (not Firefox), and importantly, only for the first attempt at pasting the URL into the address bar. All subsequent pastings cause the the page to reload, but positions it at the top (for both Edge and Chrome). Very odd.

( 2020-08-08 22:56:27 +0100 )edit

The HTML in the source for this answer is:-

<div id="post-id-258645" data-post-id="258645" class="post answer   ">


IDs are required to be unique within HTML pages. Further, the ID shows the target for an (optional) page fragment (as defined by the w3c). The way that that works is:

I've tried that just now on both Chrome & Firefox & both work.

Try https://ask.libreoffice.org/en/question/29139/#post-id-36673 - that also works (it is slightly different to the link URL).

( 2020-08-08 23:21:39 +0100 )edit

After you made it work, did you try repasting the URL into the address bar to see if you avoid the problem I reported with retries?

( 2020-08-09 19:29:13 +0100 )edit

Re-pasting the link made zero difference. It works in the same way, each time. Indeed, I see no reason why it should NOT word correctly in consecutive sessions (or at least, not unless your browser cache is badly broken).

You just do not like clicking on the tick to say "this is the correct answer", do you?

( 2020-08-09 19:51:38 +0100 )edit

I just picked up a brand new imaged computer from work and tried the above on 3 browsers. I'm still working out the configuration of the computer, but Firefox isn't working (troubleshooting that), Edge does not exhibit the problem, and Chrome does. So that's a different machine, from a work image (whereas the problem as initially encountered was reported from a personal laptop). The problem persists across different Windows 10 images, albeit not consistently across browsers. It would not be appropriate to designate your answer as the correct answer if you can't replicate the problem. Though I do appreciate that you've tried to help. Thanks.

( 2020-08-12 21:02:10 +0100 )edit

I've added extra to try to help explain why I can confidently say that it is an issue at your end & not at the server. If something is badly wrong in the routing between you & the server then you may not be receiving all of the file, or whatever. But I can get it, then (theoretically) so can you.

( 2020-08-13 00:30:06 +0100 )edit

I appreciate the technical details. I first used the "#" symbol in URLs in the mid 90's, when we (likely you) rolled our HTML my hand. I * know* that it's supposed to work, and seen it working for other URLs. I've never seen the lack of repeatability other than on the webpage cited. It's not that I don't accept the veracity of your technical explanation of how things work (as you implied). It's that I have only observed the nonrepeatability for this particular web page across different browsers and machine installations. The fact that you don't observe this is one data point. It would probably be helpful to have more. Mike Kaganski didn't observe it, for example, but that was early days before I additionally observed that the problem occurred on resubmitting the same URL in succession. He didn't mention what OS ...(more)

( 2020-08-13 14:11:15 +0100 )edit

Just tried with: https://ask.libreoffice.org/en/question/238018/#post-id-258645. It makes the browser blink in the answer, then go to the top (ratified with the help of the mobile phone video camera).

The same happen when pasting the URL of previous paragraph. Refreshing don't move from the top, but if I click in the address bar, and press Enter, answer is shown.

Something with javascript? Why does the cursor always end at the "Search or ask your question" field?

Tested with Firefox 79.0 (32-bit); OS: Windows 6.1.

( 2020-08-25 00:32:50 +0100 )edit

Something with javascript?

Not supposed to be. Fragments are an inherent feature of HTML & should therefore be an inherent feature of your browser.

( 2020-08-25 00:43:40 +0100 )edit

Problem is, I've observed the behaviour across all 3 major browsers, albeit inconsistently, on two different machines (possibly 3, I can't remember if I used the 3rd one). And I've never before seen this unreliable behaviour with another webpage. So it may be how browsers respond to other features on this webpage, such as placing the cursor in the search field, whatever the reason for that may be.

( 2020-08-25 01:13:34 +0100 )edit