638598 - Iframe parent window page does not scroll to # anchor by user interaction(click ,enter)

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Alice0775 White]

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 http://asukimi.purplesoftware.jp/top/bbs
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]

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/1ed3464aaa92
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110211 Firefox/4.0b12pre ID:20110211030400
Fails:
http://hg.mozilla.org/mozilla-central/rev/8013e7a30984
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110210 Firefox/4.0b12pre ID:20110210235042
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1ed3464aaa92&tochange=8013e7a30984

CC jonas

Comment 2

[Alice0775 White]

Also happens on Linux.
Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303122407

Comment 3

[Alice0775 White]

Attachment: Screenshot(STR)

Comment 4

[Alice0775 White]

Attachment: testcase

[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]]

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]

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]

Attachment: testcase

Comment 8

[Benjamin Smedberg]

This might be WONTFIX, but it's not a blocker in any case.

Comment 9

[Boris Zbarsky [:bzbarsky]]

See bug 583889 comment 33.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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 13

[Yuri Sulyma]

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 15

[Melissa Brenneman]

I try not to have a scroll bar for my iframe, but without one, the internal links don't work at all.

http://knoxrooms.sirsi.net/rooms/portal/page/21728_Reference

Comment 16

[Nori Hamamoto]

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.

> http://firedictionary.com/test/parent.html

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]

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 [:bzbarsky]]

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]

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 [:bzbarsky]]

The security problem is described in detail in bug 583889.

Comment 21

[Nori Hamamoto]

it sounds like a deep problem, the behavior is simple, though.

Thank you.

Comment 22

[Yuri Sulyma]

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 [:bzbarsky]]

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]

I made another example of it in which the iframe itself has a scroll bar, and
those links work without any problem.

http://firedictionary.com/test/parent2.html

If my first example ( http://firedictionary.com/test/parent.html ) 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 [:bzbarsky]]

Nori: yes, exactly.

Comment 26

[Yuri Sulyma]

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 [:bzbarsky]]

I suggest reading this bug again.  That question was already answered in comment 11.

Comment 28

[Yuri Sulyma]

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 [:bzbarsky]]

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]

Sorry, I meant the href attribute.  Basically, if B.com included

a target="frame2" href="A.com/#asdf"

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

a target="frame2" href="A.com".

However, if within A.com (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]

Hi Yuri,

You mean like this:

> http://firedictionary.com/test/parent3.html

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]

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 34

[Emanuel Kleinebekel]

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]

Come on guys you cant seriously tell me you wount fix this!?!?!

Comment 36

[Jason]

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]

@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 39

[Jonathan Protzenko [:protz]]

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 [:bzbarsky]]

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]

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 [:bzbarsky]]

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]

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 [:bzbarsky]]

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 46

[Jeroen Ruigrok van der Werven]

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]

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]

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]

This is still an Issue with FF 29.0.1

Comment 50

[Taliesin L. Smith]

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]

(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="http://example.com/book.html"></iframe>

<a name="fr1" href="http://example.com/book.html">Book</a>

<a name="fr1" href="http://example.com/book.html#chap1">Chapter 1</a>

the link to "Book" is considered secure, but the link to "Chapter1" is thought to "leak information"?

Comment 52

[kf]

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

If a webpage has this code:

<iframe name="fr1" src="http://example.com/book.html"></iframe>

<a target="fr1" href="http://example.com/book.html">Book</a>

<a target="fr1" href="http://example.com/book.html#chap1">Chapter 1</a>

the link to "Book" is considered secure, but the link to "Chapter1" is thought to "leak information"?

Comment 53

[Mossroy]

I understand that https://bugzilla.mozilla.org/show_bug.cgi?id=583889 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]

If it can help anyone else, the workaround described in http://matthewmanela.com/blog/making-linking-between-anchors-in-an-iframe-work-in-firefox-11-and-above/ worked for me

Comment 55

[Peter]

Another Sample

https://portal.airplus.com/faq.do?anchor=Security

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

  <iframe class="embedded " name="embedded" id="embedded" src="https://portal.airplus.com/html/Help_DE_en.html#Security" align="left" scrolling="auto" frameborder="0">
  <p>Unfortunately your browser cannot display embedded frames.</p>
  </iframe>


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