When Alice shares a link to a specific section in an artidoc to Bob, he is supposed to ends up directly on the targeted section, without having to scroll. Due to artidoc architecture (Front end app w/ REST calls), the sections are loaded and displayed after the initial DOM document is loaded, we cannot rely on the browser to scroll directly to the section. We have to manuall scroll to the anchor. Initial implemented worked until we introduced the possibility to add new sections: once a section is displayed(onMounted) we look at the hash and scroll to the anchor. It is not efficient because if we have 200 sections, then we will scroll 200 times to the same section. Worst, if we start to add a new section, then a pending section is displayed(onMounted), causing the scroll to anchor to occur. This means that if Bob receives a link to the 100th section, and scrolls to the beginning of the document to add a new section at the top, the browser will scroll back to the 100th section. This will be the source of WAT, confusion, WTF, and irritation for Bob. We care about Bob's sanity ʕづ•ᴥ•ʔづ♥ Let's correct this situation. The initial scroll to anchored section is now done only once, after the sections are loaded. The scroll in the section is kept to have a visible form when we add a new section. Part of story #38288: add a new section Change-Id: Ie5f4bd6325e6a462c917b2265cb6d6d947bb4ef5

+21 −17

Author

Nicolas Terray (nterray) 2024-07-04 15:37

Committer

Nicolas Terray (nterray) 2024-07-04 15:37

Hash e3499f05b560036723a89cdb3de294cc2b69620f

Parent abda850d0baa0c44527b0c6d480c203041ab647a

Reference git #tuleap/stable/e3499f05b560036723a89cdb3de294cc2b69620f