Issue31668
Created on 2017-10-03 04:35 by fireattack, last changed 2022-04-11 14:58 by admin. This issue is now closed.
| Messages (4) | |||
|---|---|---|---|
| msg303576 - (view) | Author: fireattack (fireattack) * | Date: 2017-10-03 04:35 | |
Problem This is a regression bug/flaw in Sphinx's doctools.js, a JS file used in its base template, and therefore got inherited to Python 3's documentation website. Python 2's documentation website is not affected because it's based on an older version of Sphinx. There is a function in doctools.js: /** * workaround a firefox stupidity * see: https://bugzilla.mozilla.org/show_bug.cgi?id=645075 */ fixFirefoxAnchorBug : function() { if (document.location.hash) window.setTimeout(function() { document.location.href += ''; }, 10); } This function was supposed to fix an anchor bug in Firefox (see comment). It *used to* have a condition of $.browser outside, so it will only be applied to Firefox; but it was removed in JQuery so it was removed here as well. Therefore, this function now applies to all the browsers. Unfortunately, it causes navigating problem in Chrome now, when you use back and forward. The problem STR (Chrome only): 1. Open a link with hash (anchor), e.g. https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str 2. Scroll away from the anchor position. 3. Click any external link (means the link that is not an anchor of current page). 4. Hit "back" button in the browser. What happened: When you navigating back, it doesn't go to your previous position. Instead, it goes to the anchor's location. What it should do: It should go to your previous position. Ironically, it won't cause this problem in Firefox, despite it's supposed to be a fix for (a different) anchor bug in Firefox. Comments I reported it to Sphinx as well: https://github.com/sphinx-doc/sphinx/issues/3549 but didn't get any response so far. Please keep in mind the Firefox anchor bug mentioned above will only happen if the anchor is assigned with <section id>. From my observation we don't really use <section> in HTML, so I don't think this workaround function is really necessary here to begin with. |
|||
| msg303629 - (view) | Author: Mariatta (Mariatta) * ![]() |
Date: 2017-10-03 16:39 | |
Is there anything to be done in CPython? It appears to be either a bug with the browser or Sphinx... |
|||
| msg303631 - (view) | Author: fireattack (fireattack) * | Date: 2017-10-03 16:50 | |
Well, since it affects Python's site's functionality, I thought it's appropriate to report here (with components: documentation). I followed the instruction here: https://docs.python.org/3/bugs.html#documentation-bugs It is not Sphinx's bug per se, since it has nothing to do with its software; just an ancient problematic script in template got copied here. It is not a Chrome bug, since that script was not intended to apply to Chrome to begin with. But anyway, if anyone found it's not the right place, feel free to close it. |
|||
| msg305555 - (view) | Author: Berker Peksag (berker.peksag) * ![]() |
Date: 2017-11-04 11:17 | |
This is indeed an annoying bug. Turns out there is already a compatibility shim for $.browser in doctools.js: https://github.com/sphinx-doc/sphinx/commit/c608af4babe140626877be08535af095ff633c00 I've opened https://github.com/sphinx-doc/sphinx/pull/4216 to add the "$.browser.firefox" check back. There is nothing we can do here because we don't maintain a copy of doctools.js in Python codebase: $ git ls-files | grep doctools.js Thank you for your report. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:58:53 | admin | set | github: 75849 |
| 2017-11-04 11:17:18 | berker.peksag | set | status: open -> closed nosy:
+ berker.peksag resolution: third party |
| 2017-10-03 16:50:51 | fireattack | set | messages: + msg303631 |
| 2017-10-03 16:39:56 | Mariatta | set | nosy:
+ Mariatta messages: + msg303629 |
| 2017-10-03 04:35:20 | fireattack | create | |
