Description: In Navigator, we can navigate over headings, tables, images, references, but there is no way to navigate there over footnotes or endnotes. I think there should be such an option. And by the way, it seems that Writer sometimes considers footnotes and endnotes to be references (Edit > Reference > Footnote or Endnote). So navigating over footnotes/endnotes may be "added" to navigating over references. But I'm not really sure this is a good idea. Steps to Reproduce: see above Actual Results: see above Expected Results: see above Reproducible: Always User Profile Reset: No Additional Info: see above
UX-team, Jim, do we want have all elements of the document in Navigator?
Sure, foot- and endnotes are interesting for Navigation. Would jump to the document entry not the actual text, which is pointless in particular for endnotes.
Here is a patch that adds Footnotes and Endnotes to the Navigator content tree: https://gerrit.libreoffice.org/c/core/+/122970
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fc44168ebe840fa2e772f034232fed15460e4977 tdf#144788 SwNavigator: Add footnotes and endnotes to content tree It will be available in 7.3.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 nicely but the sort order is weird when you mix endnotes and footnotes it is 1,i,2,ii,3 etc. Shall I file another ticket, Jim?
(In reply to Heiko Tietze from comment #5) > Works nicely but the sort order is weird when you mix endnotes and footnotes > it is 1,i,2,ii,3 etc. Shall I file another ticket, Jim? This happens due to using the number of the footnote/endnote to sort the list. i in the code is interpreted as 1 and ii is 2, etc which gives the result seen. The easiest thing to do code wise seems to be to list all the footnotes and then all the endnotes. So the list would look like this 1,2,3,i,ii,iii. A tool tip is displayed on mouse hover that shows Footnote or Endnote. Trying to list the footnotes and endnotes in order they appear in the document looks to be a bit of work. Perhaps separate categories listing footnotes under Footnotes and endnotes under Endnotes might be better than just one category listing both?
(In reply to Jim Raykowski from comment #6) > Perhaps separate categories listing footnotes under Footnotes and endnotes > under Endnotes might be better than just one category listing both? Too many categories spoil the broth but I could imagine a horizontal ruler as separator. Bit of a challenge on top of the sorting ;-).
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cca6092c43e6f5ff56251b2fd43e7530b99358e3 tdf#144788 SwNavigator: Group footnotes and endnotes separately It will be available in 7.3.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.
Here is a follow-up patch to separately group footnotes and endnotes under the Footnotes and Endnotes category. A separator line is shown to distinguish between footnote and endnote entries. Entries above the line are footnotes, entries below are endnotes. There is also a tool tip to distinguish between them.
Beautiful
*** Bug 148031 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #7) > (In reply to Jim Raykowski from comment #6) > > Perhaps separate categories listing footnotes under Footnotes and endnotes > > under Endnotes might be better than just one category listing both? > > Too many categories spoil the broth but I could imagine a horizontal ruler > as separator. Bit of a challenge on top of the sorting ;-). The current implementation creates a category with lots of elements. What's worse, you can't make it convenient: 1. In case there are *both* footnotes and endnotes, you will need to scroll down to an unknown position to reach endnotes - so the endnotes part is *highly* unusable; 2. When you have only footnotes, or only endnotes: 2.1. If you keep the separator, it will be an extra element in the list, and in endnotes case, it will be the top element (what is the UI concept that starts a list with "-------"?); 2.2. If you don't add the separator in that case, you have no idea if you work with footnotes or endnotes - until you double-click it. In all cases, unless you *see* the separator, when the list is long - you don't see what it is (footnote or endnote). The "------" element is *simply unnatural*. Having two categories - either top-level, or - less convenient - as sub-nodes of one top category - would be way better than this solution.
How about a filter (checkbox in context menu) to show/hide footnotes/endnotes? Anyway, this ticket is resolved fixed and commenting here feels like flogging a dead horse.
(In reply to Heiko Tietze from comment #13) > How about a filter (checkbox in context menu) to show/hide > footnotes/endnotes? Please keep it simple, in this case it means - just add another node. Anything hidden in the context menu is not obvious; people do not even know that they can limit outline levels in Navigator (from context menu). And do not try to limit number of nodes *until it actually becomes too many* - which it not at the moment. > Anyway, this ticket is resolved fixed and commenting > here feels like flogging a dead horse. Absolutely not. We even ask new contributors to create bug reports when they suggest a patch directly to gerrit, in order to have a point where the problem is explained, tracked, and *allows further discussion*. This is exactly where the "Too many categories spoil the broth but I could imagine a horizontal ruler as separator" appeared, and where the implementation was created. I do not try to re-open it, do not claim it is unfixed - but it is exactly the place to have some discussion around this fact, *before* creation of the new ticket. Please do not try to create some unnecessary limits.
*** Bug 98005 has been marked as a duplicate of this bug. ***
Dhiraj's open patch: https://gerrit.libreoffice.org/c/core/+/132796 Split up footnotes and endnotes in Navigator This patch splits the footnotes and endnotes section in Navigator. Before, there was one section for both footnotes and endnotes and now there are two sections, one for footnotes and one for endnotes.
Dhiraj Holden committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b5e838334b57fee1e38febd95f944698059dfe4a tdf#144788 Split up footnotes and endnotes in Navigator It will be available in 7.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.
I confirm the patch makes footnotes and endnotes separate categories. Unfortunately in my review of the patch I missed that footnotes aren't tracked. Here is a code pointer to make footnotes be tracked: sw/source/uibase/utlui/content.cxx SwContentTree::UpdateTracking() // footnotes and endnotes use aContentAtPos.pFndTextAttr->GetFootnote().IsEndNote() to determine if the tracking selection should be for footnote or endnote.
Hi Jim, We are getting some crash reports about lcl_SelectByContentTypeAndAddress, which was introduced by fc44168ebe840fa2e772f034232fed15460e4977 < https://crashreport.libreoffice.org/stats/signature/lcl_SelectByContentTypeAndAddress >, Any idea where the problem might be ?
(In reply to Xisco Faulí from comment #19) > Hi Jim, > We are getting some crash reports about lcl_SelectByContentTypeAndAddress, > which was introduced by fc44168ebe840fa2e772f034232fed15460e4977 < > https://crashreport.libreoffice.org/stats/signature/ > lcl_SelectByContentTypeAndAddress >, Any idea where the problem might be ? Actually the code that crashes whas introduced in f8e086f185b31f753074fd22ecc73c44b193a784
(In reply to Xisco Faulí from comment #20) > (In reply to Xisco Faulí from comment #19) > > Hi Jim, > > We are getting some crash reports about lcl_SelectByContentTypeAndAddress, > > which was introduced by fc44168ebe840fa2e772f034232fed15460e4977 < > > https://crashreport.libreoffice.org/stats/signature/ > > lcl_SelectByContentTypeAndAddress >, Any idea where the problem might be ? > > Actually the code that crashes whas introduced in > f8e086f185b31f753074fd22ecc73c44b193a784 I saw the crash reports. Seems it only happens on windows OS?
Seems the crash reports started happening after commit e00032ba6a2ddd4c08ae6f03b1982d3c099d288e changes to lcl_SelectByContentTypeAndAddress function. Only thing I see different using the template weld::fromId is the return is reinterpret_cast of string toUInt64 vs the original toInt64. reinterpret_cast<void*>(rContentTree.get_id(*xIter).toInt64()) <--- weld::fromId<void*>(rContentTree.get_id(*xIter)); template <typename T> T fromId(const OUString& rValue) { return reinterpret_cast<T>(rValue.toUInt64()); <--- }
(In reply to Jim Raykowski from comment #22) > Seems the crash reports started happening after commit > e00032ba6a2ddd4c08ae6f03b1982d3c099d288e changes to > lcl_SelectByContentTypeAndAddress function. > > Only thing I see different using the template weld::fromId is the return is > reinterpret_cast of string toUInt64 vs the original toInt64. > > reinterpret_cast<void*>(rContentTree.get_id(*xIter).toInt64()) <--- > > weld::fromId<void*>(rContentTree.get_id(*xIter)); > template <typename T> T fromId(const OUString& rValue) > { > return reinterpret_cast<T>(rValue.toUInt64()); <--- > } Let's ask Caolán about it.
(In reply to Buovjaga from comment #23) > (In reply to Jim Raykowski from comment #22) > > weld::fromId<void*>(rContentTree.get_id(*xIter)); > > template <typename T> T fromId(const OUString& rValue) > > { > > return reinterpret_cast<T>(rValue.toUInt64()); <--- > > } > > Let's ask Caolán about it. I think that's a red herring because the crashes are in 7.3 and weld::fromId isn't in 7.3. https://crashreport.libreoffice.org/stats/crash_details/cc9cb409-22b0-4336-943e-1514168657ef is an example with good line numbers that are still valid in current 7.3. It is odd that all the bt I looked at seem to involve the find bar, either crashing after pressing up/down or after FindTextFieldControl::ActivateFind but maybe that's just an artifact of the backtrace merging. I can't reproduce anything by putting hyperlinks into a document and then searching for things, that are either in the hyperlink text or not, from the findbar or pressing up/down in it.
Yes it seems to be only coincident the crash reports started to happen the day of the weld::fromId patch. Diving deeper into the report information of the branches, file, and line number shows the crash is happening in the ContentTypeID::URLFIELD block of the lcl_SelectByContentTypeAndAddress function when trying to access the GetINetAttr function. My guess is the pUserData pointer which is cast to a SwURLFieldContent pointer and used to access the GetINetAttr function is no good.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/be0f8c193316087495fd2501b3228207d4095bb5 tdf#144788 follow up: fix SwNavigator footnote tracking It will be available in 7.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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7ee7e966bd123fc571144b08bc07b1536a2e23e9 tdf#144788 follow up fix: Fix null pointer use It will be available in 7.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.
I don't know whether this is relevant or of interest: I can navigate from footnote to footnote if I place the cursor within the text of a footnote and then keep my finger on the key with the upward- or the downward-facing arrow. For me, that workaround is enough.
Fix verified in recent master build. Added to 7.3 release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F7.3&type=revision&diff=676272&oldid=666558