Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 638598 - Iframe parent window page does not scroll to # anchor by user interaction(click ,enter)
: Iframe parent window page does not scroll to # anchor by user interaction(cli...
Status: NEW
: regression, testcase
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86 All
: -- normal with 17 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
: 644158 644194 645025 667859 675024 707113 (view as bug list)
Depends on:
Blocks: 583889
  Show dependency treegraph
Reported: 2011-03-03 15:12 PST by Alice0775 White
Modified: 2016-09-25 00:00 PDT (History)
35 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Screenshot(STR) (176.89 KB, image/png)
2011-03-03 18:46 PST, Alice0775 White
no flags Details
testcase (497 bytes, application/x-zip-compressed)
2011-03-03 20:10 PST, Alice0775 White
no flags Details
testcase (470 bytes, application/x-zip-compressed)
2011-03-03 21:05 PST, Alice0775 White
no flags Details

Description Alice0775 White 2011-03-03 15:12:44 PST
Build Identifier:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110303
Firefox/4.0b13pre ID:20110303030406

Iframed page does not scroll to # anchor on certain site.
Firefox3.6.14 , Google Chrome 9.0.597.107 and Opera 11.0 works as expected.

Reproducible: Always

Steps to Reproduce:
1. Start Minefield with new profile
2. Open
3. Click [トピック表示]
4. Click a Link in the table (Ex., "ニコ生トークしようぜぃ!")
5. Click a Link in the tree (Ex. "Re: ニコ生トークしようぜぃ!" )

Actual Results:
 page does not scroll to # anchor

Expected Results:
 page should scroll to # anchor
Comment 1 Alice0775 White 2011-03-03 18:30:31 PST
Regression window:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110211 Firefox/4.0b12pre ID:20110211030400
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110210 Firefox/4.0b12pre ID:20110210235042

CC jonas
Comment 2 Alice0775 White 2011-03-03 18:36:18 PST
Also happens on Linux.
Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303122407
Comment 3 Alice0775 White 2011-03-03 18:46:45 PST
Created attachment 516773 [details]
Comment 4 Alice0775 White 2011-03-03 20:10:20 PST
Created attachment 516791 [details]

[STR for attached textcase]
1. Extract zip.
2. Open bbs-main.html
3. Click "go to aaa" link

[Expected result]
Page should be scrolled to "aaa".
Comment 5 Mike Beltzner [:beltzner, not reading bugmail] 2011-03-03 20:14:10 PST
We've built release candidates - I think this might be a .x, but I can't see us stopping the release train for this regression from Feb 10.
Comment 6 Alice0775 White 2011-03-03 20:59:01 PST
In local build,
build from 69e9525dff19 : fails
build from 1ed3464aaa92 : works

Regressed by:
69e9525dff19	Jonas Sicking — Bug 583889: Prevent scrolling from leaking information. r=dbaron a=blocker
Comment 7 Alice0775 White 2011-03-03 21:05:49 PST
Created attachment 516801 [details]
Comment 8 Benjamin Smedberg [:bsmedberg] 2011-03-04 07:28:55 PST
This might be WONTFIX, but it's not a blocker in any case.
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-03-04 09:47:19 PST
See bug 583889 comment 33.
Comment 10 Alice0775 White 2011-03-23 08:47:23 PDT
*** Bug 644158 has been marked as a duplicate of this bug. ***
Comment 11 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-03-23 11:18:36 PDT
Yeah, I think this is a WONTFIX. Otherwise you could trick the user into clicking a link targeted at an inner iframe and then measure weather that scrolls using an outer iframe.
Comment 12 Ed Morley [:emorley] 2011-03-23 15:17:21 PDT
*** Bug 644194 has been marked as a duplicate of this bug. ***
Comment 13 Yuri Sulyma 2011-03-24 02:09:29 PDT
Please fix this. This bug means that Facebook applications (which are hosted in iFrames) can't use # anchors without resorting to Javascript scrollTo() or equivalent.
Comment 14 Alice0775 White 2011-03-25 10:43:12 PDT
*** Bug 645025 has been marked as a duplicate of this bug. ***
Comment 15 Melissa Brenneman 2011-03-28 08:00:23 PDT
I try not to have a scroll bar for my iframe, but without one, the internal links don't work at all.
Comment 16 Nori Hamamoto 2011-04-05 12:35:41 PDT
The same problem has happend to me.
It's way way simple problem which is not happening on Chrome, Safari, IE8, IE7 and Firefox 3.6.7, but happening only on Firefox4.

You can see what's the problem in the following link.


The contents inside of the border is in iframe, and links to the anchors just doesn't work.
This is obviously problem.

Please, fix this!!
Comment 17 Nori Hamamoto 2011-04-05 12:42:09 PDT
Additionally, the links in the test page in the last post works on: Firefox 4.0b10, Firefox 4.0b11, but not on 4.0b12, 4.2a1pre(2011-4-5) and official release version of Firefox 4.0.
Comment 18 Boris Zbarsky [:bz] (still a bit busy) 2011-04-05 14:45:35 PDT
Nori, the problem is that the old behavior is a security bug.... that's why we changed the behavior.  See comment 11.
Comment 19 Nori Hamamoto 2011-04-05 14:59:02 PDT
Thank you for your quick reply, Boris.
My English is so poor, so I couldn't understand what is a security problem of it.
In a comment 11 says 'measure weather that scrolls using an outer iframe.'.
What I don't under stand is that mesure what? and how it affect to the security problem. Please let me know that.
Comment 20 Boris Zbarsky [:bz] (still a bit busy) 2011-04-05 15:06:37 PDT
The security problem is described in detail in bug 583889.
Comment 21 Nori Hamamoto 2011-04-05 15:11:30 PDT
it sounds like a deep problem, the behavior is simple, though.

Thank you.
Comment 22 Yuri Sulyma 2011-04-05 15:23:47 PDT
My understanding is that bug 583889 has do do with scrolling OUTER frames (although there are legitimate situations where that is required); Nori's example shows that iframes aren't able to scroll _themselves_.
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2011-04-05 15:33:34 PDT
In Nori's case the iframe doesn't scroll, since it's big enough for the content.  the only thing that can scroll is the outer browser window containing the iframe.
Comment 24 Nori Hamamoto 2011-04-05 15:41:32 PDT
I made another example of it in which the iframe itself has a scroll bar, and
those links work without any problem.

If my first example ( ) works, an
iframe leaks an information of if some certain id is contained in the inner
document because we can control the url of iframe through iframe.src property.

This is a problem of a case if the first example working, right Boris?
Comment 25 Boris Zbarsky [:bz] (still a bit busy) 2011-04-05 15:51:39 PDT
Nori: yes, exactly.
Comment 26 Yuri Sulyma 2011-04-05 16:34:56 PDT
What is the problem with:

a) allowing iFrames to scroll themselves
b) ignoring the fragment identifier on the src attribute of cross-domain iFrames

Comment 27 Boris Zbarsky [:bz] (still a bit busy) 2011-04-05 16:40:00 PDT
I suggest reading this bug again.  That question was already answered in comment 11.
Comment 28 Yuri Sulyma 2011-04-05 16:43:32 PDT
The exploit described in comment 11 only works if the outer frame can cause the inner frame to scroll using a fragment identifier.  If the fragment identifier were ignored on cross-domain iframes, no scrolling would occur.
Comment 29 Boris Zbarsky [:bz] (still a bit busy) 2011-04-05 16:48:19 PDT
No, you didn't read comment 11 carefully enough...  The src attribute is not being set there.

As far as restricting to cross-domain, this was discussed in bug 583889.  Potentially doing such a restriction is the only reason this bug is still open.
Comment 30 Yuri Sulyma 2011-04-07 19:37:14 PDT
Sorry, I meant the href attribute.  Basically, if included

a target="frame2" href=""

where !=, then the fragment identifier would be ignored, i.e. it would be equivalent to

a target="frame2" href="".

However, if within (frame2), the user clicked on the link

a href="#asdf"

then the iframe would scroll to #asdf as usual.  What's wrong with this?
Comment 31 Nori Hamamoto 2011-04-08 10:06:34 PDT
Hi Yuri,

You mean like this:


I made a sample web page showing how a link targeted to an iframe works.
It looks like a fragment identifier in a link works for both the same domain and a different domains on Firefox 4.0.

Do I misunderstand something?
Comment 32 Jean-Christophe Direur 2011-05-28 14:56:49 PDT
We use frame in same domain origin: top, left, bottom menu in iframe parent and content in iframe child.

But the implementation for bug 583889, i understand the security problem, is a big regression for user convenience.

What can we do to solve that?

(sorry for my english).
Comment 33 Cork 2011-06-28 10:09:07 PDT
*** Bug 667859 has been marked as a duplicate of this bug. ***
Comment 34 Emanuel Kleinebekel 2011-06-28 11:28:00 PDT
Sry but maybe I am too stupid to check the "security" reasons or my english is not good enought to understand everything (COmment 11 here and #583889 Bug), but I cant see any "security" reason?

I got a simple example. If you sell things on ebay your article description will be inserted like an iframe (without scroling!!!!) - so anchors will not work on ebay article descriptions - BIG FAIL!!!! Dont ask me how but i cant find any iframe tags on the ebay source code but its defenetly any kind of frame because i can right click anywhere in the description and choose (free tranlated) "current frame" -> "show only this frame" <- dont know how its exactly called in englisch firefox version.

So what to do? I cant believe that this wount be possilble in any future firefox version. If it is, than I am so sorry to be forced changing my browser. So please fix it. 

Again you cant tell me that >> klicking << an anchor in iframe mean any security reason for the page visitor using firefox!?!?! I cant recognize the email example on ticket #583889. If I understand that ticket correct he means only the possibility to insert a external web page with an #anchor but not klicking it!?!?!
Comment 35 Emanuel Kleinebekel 2011-06-29 01:04:53 PDT
Come on guys you cant seriously tell me you wount fix this!?!?!
Comment 36 Jason 2011-07-06 07:53:46 PDT
Why is this bug not being fixed?  I don't understand how using an intrapage link within an iFrame can be a big security hole.  "Back to top" links within a Yahoo Store are no longer working.  Also, users cannot drill down to specific content.  Please explain why other major browsers do not feel this is a security concern, but Firefox does?  Thanks for your time.
Comment 37 Emanuel Kleinebekel 2011-07-06 07:56:49 PDT
@Jason read the whole Request - They dont think this is a bug because they dont understand that klicking and inserting are two different cases... Thats what I try to explain but they didnt answer...

Comment 38 Mats Palmgren (:mats) 2011-08-11 13:41:46 PDT
*** Bug 675024 has been marked as a duplicate of this bug. ***
Comment 39 Jonathan Protzenko [:protz] 2011-08-11 14:20:48 PDT
Is there any way to revert to the previous behavior when the outer page has chrome privileges? Would that be very involved or would that just involve setting the right flag? I'm asking because that will be a problem for Thunderbird when we switch to displaying emails using seamless iframes (once bug 80713 is fixed), and this is already a problem for Thunderbird Conversations (an official Messaging extension).

Restricting this behavior to cross-domain would indeed be better but that sounds more elaborate.
Comment 40 Boris Zbarsky [:bz] (still a bit busy) 2011-08-11 15:06:00 PDT
If the outer page has chrome privileges, presumably it's in a chrome-type docshell too.  And if the subframe is content-type, then the scroll wouldn't have affected the outer page in the past either...

Emanuel, it's very clear that clicking and inserting are different things; that's why this bug is still open.  One problem is getting that information to the point that needs to make the scroll decision.
Comment 41 steven 2011-09-28 17:24:11 PDT
Having read the security issue, I don't understand why this should block a tall inner iframe from scrolling the outer iframe when the inner frame targets one of its *own* anchors.

The inner frame has no way of verifying whether the parent's scrolling position changed, as that information is subject to same-origin-policy. All it cares about is that the browser is going to make a reasonable effort to make that anchor visible.
Comment 42 Boris Zbarsky [:bz] (still a bit busy) 2011-09-28 18:33:55 PDT
steven, in the scenario you describe the outer frame can spy on what the inner frame is doing by observing its own scroll position if it gets scrolled.  Which would violate the same-origin policy.  In this case the inner frame is being protected from the outer one, not vice versa as you seemed to think.
Comment 43 steven 2011-09-28 18:57:36 PDT
Boris: no, we're talking about two different things.

The security issue you describe occurs when the outer iframe navigates the inner iframe to an anchor. I agree this is an issue.

What I'm describing is when the *inner* iframe navigates to one of its own anchors, but when overflow / layout requires the outer iframe to scroll to actually achieve this. This does not seem like a case where information leakage can occur, and yet it is currently forbidden.
Comment 44 Boris Zbarsky [:bz] (still a bit busy) 2011-10-03 21:54:27 PDT
steven, I know what you're describing.  I was talking about the same exact thing.

Say the outer frame places the inner frame such that its top is at the bottom of the outer frame when the outer frame is scrolled all the way to top and gives it a very large height, to make sure that no scrolling will actually happen in the inner frame.  Then when the inner frame navigates to an anchor, if this caused the outer frame to scroll the outer frame would be able to read its own scroll position, which will exactly match the location of the anchor in the inner frame, which leaks information from the inner frame (the anchor it navigated to) to the outer frame.

This is indeed not the same issue as bug 583889: that was about the inner frame leaking information about whether it has an id.  But leaking information about which anchor you're going to is also bad.
Comment 45 Alice0775 White 2011-12-02 03:44:52 PST
*** Bug 707113 has been marked as a duplicate of this bug. ***
Comment 46 Jeroen Ruigrok van der Werven 2012-01-17 06:40:39 PST
I am running into this issue as well. I have a static webpage with same-page anchors that gets iframe included on a larger page part of our larger site. Every single browser *EXCEPT* Firefox works with the same-page links. Somehow I doubt that all the developers on the other browser teams are unaware of the problems of leaking. So why is Firefox solving this problem with an obvious regression in usability?
Comment 47 jsp 2012-08-29 06:17:47 PDT
Bug 583889 says "dbaron asked that we don't apply different rules for cross-site and same-site, which I [sicking] agree is a laudable goal."  Comment 29 indicates that this bug remains open because there's some uncertainty about this.  In the interest of furthering the discussion, I'd like to point out that even if the goal is desirable, Firefox's current behavior is problematic in at least one case.

Posit an iframe on a page with script that attempts to size the frame to fit its content, thus avoiding a scroll bar on the frame.  The script is constructed to use a default frame size if it cannot obtain the content height.

If the content is cross-domain, the script is forbidden access to its height.  The script uses the default frame size, the frame gets a scroll bar if it needs it, and links between sections of the frame's content cause the frame to scroll if necessary.

If the content is same-site, however, the script is granted access to its height.  The script sizes the frame to match the content.  Links between sections of the frame's content do not scroll the page if necessary to bring the target into view.

This inconsistency is astonishing, and as a page developer, I haven't come up with a way to protect users from it.  To be consistent, I think Firefox would have to use the same rules for scrolling that apply to access to the iframe's contents.  That either means restricting access to iframe content regardless of whether it's cross-domain or same-site, or allowing the page to scroll when a page-internal link inside same-site iframe content is clicked.  The former seems needlessly limiting.
Comment 48 Ali 2012-11-16 14:14:41 PST
Any chance this can at least be fixed for the same-origin case until a final decision is made on this bug? There are many iframes that resize to fit their content and this is causing navigation issues with content inside those iframes.
Comment 49 Stevanicus 2014-06-03 02:51:55 PDT
This is still an Issue with FF 29.0.1
Comment 50 Taliesin L. Smith 2014-08-31 09:29:25 PDT
This bug is a serious problem for users and course developers that use Desire2Learn, a learning management system. This learning management system depends on iframes. All course content is delivered through an iframe so no internal page anchors will work including "back to top" links which exist on almost every page of every course. I can't change the LMS, I can only change course content. My choices are: 1. do not use page anchors to enhance internal page navigation and design, or 2. Direct all university instructors and students at our institution to use a different browser. Neither of these solutions is desirable.

Please fix this bug. Internal page anchors are a very popular means of page navigation. These links work in all other major browsers.
Comment 51 kf 2014-09-02 06:59:04 PDT
(In reply to Jonas Sicking (:sicking) from comment #11)
> Yeah, I think this is a WONTFIX. Otherwise you could trick the user into
> clicking a link targeted at an inner iframe and then measure weather that
> scrolls using an outer iframe.

Just to make sure I'm understanding the issue correctly....

If a webpage has this code:

<iframe name="fr1" src=""></iframe>

<a name="fr1" href="">Book</a>

<a name="fr1" href="">Chapter 1</a>

the link to "Book" is considered secure, but the link to "Chapter1" is thought to "leak information"?
Comment 52 kf 2014-09-02 07:06:52 PDT
Just to make sure I'm understanding the issue correctly....

If a webpage has this code:

<iframe name="fr1" src=""></iframe>

<a target="fr1" href="">Book</a>

<a target="fr1" href="">Chapter 1</a>

the link to "Book" is considered secure, but the link to "Chapter1" is thought to "leak information"?
Comment 53 Mossroy 2014-09-19 08:30:27 PDT
I understand that has been done to fix a potential cross-site security issue.

If I understood correctly, that's the reason why anchors have been disabled when they are in an iframe.

But wouldn't it be possible to allow them when the iframe is in the same site?
We have this case and would like to have at least a workaround...
Comment 54 Mossroy 2014-10-03 08:52:36 PDT
If it can help anyone else, the workaround described in worked for me
Comment 55 Peter 2014-10-23 08:28:53 PDT
Another Sample

This JSP page is rendering an iframe with the parameter anchor as anchor to the iframe.

  <iframe class="embedded " name="embedded" id="embedded" src="" align="left" scrolling="auto" frameborder="0">
  <p>Unfortunately your browser cannot display embedded frames.</p>

Neither the original link is selected, nor any other anchor that is clicked from within the iframe.

Note You need to log in before you can comment on or make changes to this bug.