Open
Bug 638598
Opened 13 years ago
Updated 1 year ago
Iframe parent window page does not scroll to # anchor by user interaction(click ,enter)
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: alice0775, Unassigned)
References
()
Details
(Keywords: regression, testcase)
Attachments
(2 files, 1 obsolete file)
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
![]() |
Reporter | |
Comment 1•13 years ago
|
||
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
![]() |
Reporter | |
Updated•13 years ago
|
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
![]() |
Reporter | |
Comment 2•13 years ago
|
||
Also happens on Linux. Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303122407
OS: Windows 7 → All
![]() |
Reporter | |
Comment 3•13 years ago
|
||
![]() |
Reporter | |
Comment 4•13 years ago
|
||
[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•13 years ago
|
||
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.
![]() |
Reporter | |
Comment 6•13 years ago
|
||
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
![]() |
Reporter | |
Comment 7•13 years ago
|
||
Attachment #516791 -
Attachment is obsolete: true
![]() |
Reporter | |
Updated•13 years ago
|
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
![]() |
Reporter | |
Updated•13 years ago
|
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
![]() |
Reporter | |
Updated•13 years ago
|
Summary: Iframe page does not scroll to # anchor if the iframe is defined css height → Iframe parent window page does not scroll to # anchor
![]() |
Reporter | |
Updated•13 years ago
|
Summary: Iframe parent window page does not scroll to # anchor → Iframe parent window page does not scroll to # anchor by user interaction(click ,enter)
Comment 8•13 years ago
|
||
This might be WONTFIX, but it's not a blocker in any case.
blocking2.0: ? → -
![]() |
||
Comment 9•13 years ago
|
||
See bug 583889 comment 33.
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
Nori, the problem is that the old behavior is a security bug.... that's why we changed the behavior. See comment 11.
Comment 19•13 years ago
|
||
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•13 years ago
|
||
The security problem is described in detail in bug 583889.
Comment 21•13 years ago
|
||
it sounds like a deep problem, the behavior is simple, though. Thank you.
Comment 22•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
Nori: yes, exactly.
Comment 26•13 years ago
|
||
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•13 years ago
|
||
I suggest reading this bug again. That question was already answered in comment 11.
Comment 28•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
Come on guys you cant seriously tell me you wount fix this!?!?!
Comment 36•12 years ago
|
||
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•12 years ago
|
||
@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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
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•9 years ago
|
||
This is still an Issue with FF 29.0.1
Comment 50•9 years ago
|
||
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•9 years ago
|
||
(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•9 years ago
|
||
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•9 years ago
|
||
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•9 years ago
|
||
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•9 years ago
|
||
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.
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•1 year ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•