Open Bug 638598 Opened 12 years ago Updated 6 months ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: alice0775, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(2 files, 1 obsolete file)

Screenshot(STR)
176.89 KB, image/png
Details
testcase
470 bytes, application/x-zip-compressed
Details 
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
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
blocking2.0: --- → ?
Keywords: regression
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Also happens on Linux.
Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303122407
OS: Windows 7 → All
Attached image Screenshot(STR) — 

    
    

    
  

      
      
      
      

        Attached file
          
        testcase (obsolete)
        — 
      

    


  
[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".

    
  
Keywords: testcase

    
    

    
  
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.

    
    

    
  
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
Blocks: 583889

    
    

    
  

      
      
      
      

        Attached file
          
        testcase
        — 
      

    


  

        Attachment #516791 -
        Attachment is obsolete: true

    
  
Summary: Iframe page does not scroll to # anchor on certain site → Iframe page does not scroll to # anchor on certain site if the iframe is defined css height

    
  
Summary: Iframe page does not scroll to # anchor on certain site if the iframe is defined css height → Iframe page does not scroll to # anchor if the iframe is defined css height

    
  
Summary: Iframe page does not scroll to # anchor if the iframe is defined css height → Iframe parent window page does not scroll to # anchor

    
  
Summary: Iframe parent window page does not scroll to # anchor → Iframe parent window page does not scroll to # anchor by user interaction(click ,enter)

    
    

    
  
This might be WONTFIX, but it's not a blocker in any case.
blocking2.0: ? → -

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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

    
    

    
  
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!!

    
    

    
  
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.

    
    

    
  
Nori, the problem is that the old behavior is a security bug.... that's why we changed the behavior.  See comment 11.

    
    

    
  
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.

    
    

    
  
The security problem is described in detail in bug 583889.

    
    

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

Thank you.

    
    

    
  
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_.

    
    

    
  
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.

    
    

    
  
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?

    
    

    
  
Nori: yes, exactly.

    
    

    
  
What is the problem with:

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

?

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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?

    
    

    
  
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?

    
    

    
  
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).

    
    

    
  
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!?!?!

    
    

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

    
    

    
  
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.

    
    

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

:(

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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?

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
This is still an Issue with FF 29.0.1

    
    

    
  
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.

    
    

    
  
(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"?

    
    

    
  
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"?

    
    

    
  
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...

    
    

    
  
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

    
    

    
  
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.
Component: DOM → DOM: Core & HTML

    
  
Severity: normal → S3

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