WebHelp Pro expand/collapse book of topics not working
Reported by
rie...@gmail.com,
Dec 30 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36 Example URL: https://zendesk.spacetimeinsight.com/ta/tahelp1.3/Tutorial_Application.htm Steps to reproduce the problem: 1. Open the URL provided 2. Try and expand/collapse the books in the TOC panel on the left 3. You cannot expand/collapse when using Chrome 63.x This has worked in all previous versions of Chrome, including 62.x What is the expected behavior? That expand/collapse continue to work. What went wrong? Upgrading to Chrome 63.x. This works with previous versions of Chrome and with all other browsers that I have tried on both Mac and Windows. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes 62.x Does this work in other browsers? Yes Chrome version: 63.0.3239.108 Channel: stable OS Version: OS X 10.13.2 Flash Version: Shockwave Flash 28.0 r0 The URL is output from RoboHelp v10 - and generally referred to as WebHelp Pro. Up until and including Google Chrome 62.x I had no problems expanding and collapsing books with topics in the ToC panel in the WebHelp Pro output. As of Google Chrome 63.0.3239.84 (and .108) the expand and collapsing of books in the ToC is no longer possible. Same expand/collapse functionality also works fine in other browsers (IE, Edge, Firefox, Safari). Only Chrome from version 63.x seems to exhibit this issue. Would anyone have any clues if this is fixable with workaround or some "hidden" setting?
,
Jan 1 2018
I bisected on Mac, twice, to this: https://chromium.googlesource.com/chromium/src/+log/ac3e881ccf55479e3acc13ebb8a62eb2cfe17a2c..55dc1f8189d76c7ed7d9d3878c22c08e300669e3 That range has nothing that really jumps out at me. The page uses JS to modify the DOM when the tag is clicked, so I have to think the blame patch is: https://chromium.googlesource.com/chromium/src/+/8ff781cd5c1aabca068247de9a3f143645e80422 I suggest locally reverting that patch to see if the problem goes away. If that patch is to blame it may be a page error, because the patch description claims this improves spec compliance.
,
Jan 2 2018
Reverting my patch does fix the issue. However, I think it's a design issue in the site, rather than my patch causing regression. The site uses innerText for cross-referencing purposes, which should be done using element id or JS variables instead. More technical details of the issue: 1. The site calls expandToc() (whthost.js:836) on load 2. At whthost.js:867, it runs sText = getInnerText2(aChildren[i]) With old Chrome versions: 3. sText gets value "Introduction\n"; Then the next line removes the trailing '\n' 4. whthost.js:869 sees sText == sPart, and does not skip the remaining processing With current Chrome 3. sText gets value "Introduction\n\n"; Then the next line removes only one of the trailing '\n's 4. whthost.js:869 sees sText != sPart, and skips the remaining processing So my suggestion is to revise the site implementation. A short term solution is to fix the trailing '\n' removal, and probably merge it into getInnerText2. A better fix is not to use innerText for cross-reference at all.
,
Jan 3 2018
totally appreciate the quick turnaround and suggested workaround solution. We have implemented as suggested in Comment 3 and it works nicely within our solution. Many thanks again!!
,
Jan 3 2018
#4: Great to hear that! |
|||
►
Sign in to add a comment |
|||
Comment 1 by krajshree@chromium.org
, Dec 31 2017