87460 - "Show Only This Frame" should prevent forced reframing

Status: NEW

(Core :: General, enhancement, P5)

Description

[Cesar Eduardo Barros]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010622
BuildID:    2001062212

Some pages use JavaScript to force the user into a frame. "Show Only This Frame"
should prevent this reframing.

Reproducible: Always
Steps to Reproduce:
1. Go to the site
2. On the largest frame (the one on the top, with the _real_ content) select
"Show Only This Frame" from the context menu

Actual Results:  The frameset came back

Expected Results:  Mozilla should have pretended the page was still in the
frameset (i.e. the frameset is still there, we're just showing only one of the
frames and not even bothering to load the rest of them). Or do some hairy evil
thing which would never work quite right to prevent any kind of frameset-forcing
JavaScript. The first option is probably better.

Comment 1

[Boris Zbarsky [:bzbarsky]]

this is already filed

Comment 2

[doctor__j]

Do you mean bug 81084?

Comment 3

[Boris Zbarsky [:bzbarsky]]

I do indeed.  Thanks, [e-mail]

*** This bug has been marked as a duplicate of 81084 ***

Comment 4

[Boris Zbarsky [:bzbarsky]]

Hmm.  Read this again.  Reopening.  The idea here seems to be to change the
implementation of "show only this frame" to resize frames instead of loading the
document in the frame in the full browser...  That might actually be a decent
idea, assuming that context menu problems are ironed out.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Over to XP apps.

Comment 6

[sairuh (rarely reading bugmail)]

see this on mac and winnt [comm branch] bits as well.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

I think this is in fact a dupe of 81084, but this oes seem like a reasonable
approach if someone wants to implement it. We need to think it through though.
What would ahppen to the "hidden" frames when the user clicks away from that page?

Comment 8

[Cesar Eduardo Barros]

What happens to normal frames.

There's no real difference, you're still there within a frameset; _top will kill
them, and targeting the current frame keeps them. Targeting another frame moves
your point of view to that frame.

Comment 9

[sairuh (rarely reading bugmail)]

marking p5, future, and helpwanted

Comment 10

[Jesse Ruderman]

*** Bug 82256 has been marked as a duplicate of this bug. ***

Comment 11

[Asa Dotzler [:asa]]

-> default assignee

Comment 12

[Jesse Ruderman]

Mozilla could bring the frame to the top without re-parsing the page.  That
would make "show only this frame" faster and more accurate while at the same
time ignoring forced-reframe scripts (which are intended to fix external links,
not to annoy visitors).  Opera avoids re-executing javascript for back and
forward but surprisingly gets this case wrong.

Comment 13

[Ben Bucksch (:BenB)]

my 2 cents: just redisplaying the frame, without triggering onload or the like
seems like the better idea. With "Show only this frame", I expect that the other
frames are *gone*, that this frame is liek a normal page from now on, but that
the frame doesn't reload or anything like the current implementation seems to
do. Not sure, how difficult that would be to implement.

Comment 14

[Peter Trudelle]

Mass moving all of my open Nav/toolkit bugs to new owner.

Comment 15

[Prognathous]

Previous test URL was dead, replacing with one that works.

Prog.

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 23

[Jesse Ruderman]

This is an enhancement request (with 9 votes!).  Enhancement requests do not expire.

Comment 24

[Stewart Gordon]

Why has the exact same comment been posted 7 times?

Comment 25

[Jesse Ruderman]

That was a bug in Bugzilla, more or less.

Comment 26

[Robert Kaiser]

SeaMonkey team can't fix this, I see this as WONTFIX in SeaMonkey-specific terms, but I'll let you keep it alive elsewhere, this belongs somewhere into Core but I have no clue where.

Comment 27

[wzkkr]

Many link agregating pages uses (i)frames to view submited links -> submited page in big frame and footer/header frame with some social options, ads, etc. Many portals didin't like that and used JS to jump out from frame. Just now I saw link agregate that prevents pages to break free from frame:
<script type="text/javascript">
    var prevent_bust = 0  
    window.onbeforeunload = function() { prevent_bust++ }  
    setInterval(function() {  
      if (prevent_bust > 0) {  
        prevent_bust -= 2  
        window.top.location = 'http://linkagregate.com/someurl.php'
      }  
    }, 1)  
</script>
The issue is that this JS code also prevents "Show only this frame" from working at all (FX 3.5.7). Implementing "Show only this frame" as "hide other frames" would help but real solution would be option to block onbeforeunload(). Sadly it is also used by legitime uses like some AJAX apps.