56743 - (frame-off) Add option to disable frames/force noframes

Status: RESOLVED WONTFIX

(Core :: Layout: Images, Video, and HTML Frames, enhancement, P3)

Description

[Robin Lionheart]

A useful feature of Opera is the ability to disable frames. This makes it easier to get bookmarkable URLs for subframe pages, and to test accessibility. (Both as a web developer and as a reviewer for the Open Directory Project.)

Mozilla's inability to render NOFRAMES content can also interfere with pages which are designed to look one way inside a frameset and another way outside of one. See bug 47658.

Mozilla has options to disable Java, JavaScript, image loading, cookies, and to a limited extent style sheets. Why not frames?

Comment 1

[Eric Pollmann]

Taking a stab at a milestone - CC'ing Harish as this relates to work he is doing.

Comment 2

[Eric Pollmann]

See related bug 47658

Comment 3

[Amarendra Hanumanula]

QA Contact update

Comment 4

[Eric Pollmann]

We need to enable support in gecko (bug 69455) then we can add a preference and
a UI (this bug).

Comment 5

[Kevin McCluskey (gone)]

Bulk reassignin HTML FRAME/IFRAME bugs to Eric.

Comment 6

[Matthew T (active 1999-2002)]

Bug 89557 is for the GUI. This bug can be marked fixed when there is a back-end 
pref for disabling frames, and a back-end pref for disabling iframes (which 
generally aren't as annoying as frames so should be controlled independently).

Comment 7

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 8

[Kevin McCluskey (gone)]

Bulk re-assigning all of Eric's HTMLFrame bugs to John.

Comment 9

[John Keiser (jkeiser)]

IF this option is implemented, it will need to have special code to show links
to the various frames in the frameset.  NOFRAMES content would be shown if it
was there; but I think both need to be shown at all times because on many pages,
NOFRAMES is just a useless patronizing diatribe against "users with obsolete
browsers that don't support frames."  The links could be in a sidebar tab
potentially.  JavaScript and links in those frames will likely open new windows.

Because it will contain much new code and large numbers of codepaths, it has to
be useful enough for many users to use.  Otherwise the codepaths will be
untested and rot; and *worse*, frame, form and link developers will be forced to
think about this new pref for every link-clicking, URL-resolving, window-opening
feature they hack on or add.  New restrictions should not be lightly draped upon
programmers; we have more than enough complexity to go around already.

On the plus side, as timeless points out, this will presumably make Mozilla more
useful on small screens and PDAs; frames tend to take up more space than
necessary on these devices, and usually at the left top where you start scrolling.

Comment 10

[Akkana Peck]

> The links could be in a sidebar tab

People who turn off frames probably also are not using a sidebar, for the same
reason (conservation of screen real estate) and do not want to see the content
of the other frames.

> this will presumably make Mozilla more useful on small screens and PDAs

Agreed.  The Palm-based browsers I've used generally request the NOFRAMES
content anyway. Now and then I see "This page uses frames and your browser
doesn't support them", which doesn't bother me any more than pages that depend
on Java or Flash or inline images -- it's a sign of a bad page author, not a bad
browser.

Comment 11

[John Keiser (jkeiser)]

If people do not want to see the content of other frames, period, then they
could turn off the sidebar and turn it back on when they want to see them again
... or we could print them in the browser window or in a special Frames Toolbar
with options like the Links Toolbar (disable always, enable only when frames
appear, enable always).  If we present them in the browser window that could
make things a little ugly, especially if your experience is the common one and
NOFRAMES content is generally more than just "your browser doesn't support
frames, stupid."  Perhaps we should go with another timeless suggestion in this
case, and use the size of the content to decide whether or not to display the
links to the frames.  This makes me queasy.

PDAs already request NOFRAMES?  Well, if your user experience with it is such
that you can usually see pages, that pretty much deals with my argument that you
shouldn't disable frames.  Akkana, have you noticed what those PDA browsers do
in the case that there are frames but no NOFRAMES content?

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[Robin Lionheart]

Coping "force noframes" from subject of duplicate bug so searchers may find this one with 'noframes' searches.

Comment 14

[Vedran Miletic]

retargeting

Comment 15

[Jesse Ruderman]

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

Comment 16

[Artem S. Tashkinov]

I wonder if it's really that difficult to solve this six(!) years old bug. After all it's just a matter of adding a new setting (which might be presented only in userprefs.js) and a simple

if (iframes.enabled) {
  render(iframe);
}
else {
  content = parse_tag(iframe);
  print(content);
}

in the browser source file.

Comment 18

[Boris Zbarsky [:bzbarsky]]

We are not going to implement this.