搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

Learn More

Why does FF 56.0.2 'jump' to the bottom of a page upon loading?

more options

I'm on MacOS Yosemite using Firefox 56.0.2. When I navigate from page to page on the Turbotax 'AnswerXchange' site, each page loads and then 'jumps' to the bottom of the page. This does NOT happen on Safari or Chrome, or on Firefox 48.0.2 on two other Snow Leopard systems. This didn't happen with my prior version of Firefox on Yosemite. This problem may have been corrected. However, my guess is that it's related to "href='\#\'" in the attachment that I was planing to attach, but can't upload because it's an HTML file, not an Image. Maybe I can email it to someone who asks me for it. I can then email it back as an attachment. All that's necessary to test it is to "Open File" with Firefox. For me, after loading, Firefox 'jumps' to the end of the page. My email address is in My Profile.

I'm on MacOS Yosemite using Firefox 56.0.2. When I navigate from page to page on the Turbotax 'AnswerXchange' site, each page loads and then 'jumps' to the bottom of the page. This does NOT happen on Safari or Chrome, or on Firefox 48.0.2 on two other Snow Leopard systems. This didn't happen with my prior version of Firefox on Yosemite. This problem may have been corrected. However, my guess is that it's related to "href='\#\'" in the attachment that I was planing to attach, but can't upload because it's an HTML file, not an Image. Maybe I can email it to someone who asks me for it. I can then email it back as an attachment. All that's necessary to test it is to "Open File" with Firefox. For me, after loading, Firefox 'jumps' to the end of the page. My email address is in My Profile.

所有回覆 (11)

more options

To demonstrate, I created a web-page that shows the problem. Visit: < web.stanford.edu/~guertin/ttlc.intuit.com.html >

由 DICKGUERTIN 於 修改

more options

Thanks for the demo page. One possible explanation for this is that some scripts in the page (actually, on CloudFront) embed a frame at the bottom of the page, with this address:

https://accounts.intuit.com/ividFrame.html?ivid_b=f6534625-0d0d-4d40-b07b-83ed8bd4178f

That doesn't display any content, but perhaps something in the script attracts the cursor to that area?? I can't really tell.

Also, I say "at the bottom" but there is a style rule placing it 200 pixels above the top of the page, so it's in a non-viewable margin area, which may or may not be contributing to the odd behavior.

more options

jscher2999, that reference you cited isn't really empty. It's almost two pages of html-code, but it doesn't have a DOCTYPE header, and begins after two blank lines. Why it doesn't show anything is weird, BUT this doesn't explain the behavior of the original page that displays just fine on Safari, Chrome, and other versions of Firefox (prior to 52.0.2). I still think it's associated to several 'href="#"' lines, and the one line that should be a 'name="#", but is 'href='\"#\"' instead. It acts like a #tag on the original page, something like this: < http://web.stanford.edu/~guertin/MLS.html#0400 >.

PS, I apologize for all the 'blank' 'Quote' items. I finally realized I should Edit instead of Quote. But how could I delete all those mistakes? There doesn't seem to be a way to do that.

由 DICKGUERTIN 於 修改

more options

Based upon my hunch that it's the hrefs that are causing troubles, I edited the saved demo-page changing "#" into "#0" in the hrefs, and then changing: href='\"#\"' into: id="0" which makes it a valid target for the hrefs. THAT WORKS in Firefox 56.0.2, and you can see it yourself: web.stanford.edu/~guertin/ttlc2.intuit.com.html

You can also view the changes: web.stanford.edu/~guertin/html.diff.txt

Obviously, I have to contact Intuit about changing their web-sire pages. But this still doesn't explain why Firefox 56.0.2 is handling it WRONG when other browsers (Safari, Chrome, and older Firefox) all get it RIGHT.

由 DICKGUERTIN 於 修改

more options

Okay, but we can observe that neither # or #0 is ending up on the address bar as you would expect from basic hash navigation. If for some odd reason Firefox is activating one of those links, the assigned click handling script is capturing the "click". Assuming that supposition is correct, why is the script moving the scroll position to the bottom only in Firefox??

more options

There is a difference between # and #0 because # by itself is invalid. It's supposted to be followed by a name-tag, such as #leave or #234. Also, the target isn't defined properly. Instead of id=tag it's href='\"#\"', and I suspect that what's triggering the 'jump to the invalid target'.

There's now a battle going on between Mozilla and Intuit. I have posts on the AnswerXchange about this, and they claim it's the browser's fault, especially since it only 'jumps' for Firefox, NOT any other browsers

I've claimed it's Intuit's fault for having 'improper' hrefs and targets, which should be id=tag, NOT href=pseudo-tag.

My question at this point is simply this: Does the demo-page that shows the jump do the same thing in newer version of Firefox? I'm not willing to abandon my Add-On Extensions, so I haven't updated past 56.0.2.

由 DICKGUERTIN 於 修改

more options

Yes, same behavior in Firefox 58. However, when I test https://ttlc.intuit.com/ in the Extended Support Release of Firefox 52, the scroll position does not change. So that started some time after Firefox 52. I don't know whether I'm patient enough to track that down, considering the substantial length of time between Firefox 52 and Firefox 56.

While href="#" is a link to nowhere, it's a common design pattern when scripts are used only as an attachment point for scripts. Another common pattern is href="javascript:void(0)" which is even more of a "do nothing" link.

The external script files are very large and impractical for me to debug. Hopefully someone who understands the site knows can figure out why the navigation is triggered.

more options

jscher2000, I consider this something Intuit can easily fix in their own web-pages by using standard < a href="#0" /> and < a id="0" /> terms. Those should work everywhere.

more options

This change seems to have been introduced in March 13-14, 2017, Firefox 55 time frame, but my regression tests keep crashing so I haven't found the exact change. Frustrating. Too late tonight.

more options

jscher2000, I agree that the 'change' should be found, and repaired. On the other hand, it's really bad-coding practices on the part of AnswerXchange. A simple fix there eliminates the problem at its source. I've explained the fix on the AnswerXchange itself; but who knows if they will make a correction.

more options

Hi DICKGUERTIN, I filed a bug for this problem in Mozilla's "Bugzilla" bug tracking system:

https://bugzilla.mozilla.org/show_bug.cgi?id=1436906

If only one site is affected, it may not get a high priority. If you notice it anywhere else, we can add that information to the bug.