Closed Bug 105797 Opened 23 years ago Closed 23 years ago

Pref to force frames to be resizable


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

Not set





(Reporter: mpt, Assigned: bzbarsky)




(4 files, 2 obsolete files)

Web authors often make incorrect assumptions about the margins a UA will apply 
to their page. They then present frames which would be completely visible if 
they were just a little bit taller/wider, but which have the NORESIZE attribute 

Therefore, Mozilla should provide a pref to force frames to be resizable, by 
ignoring NORESIZE. This bug is spun off from bug 89557, which would provide a 
GUI to expose the pref.

Problem occurs in: Mozilla
Problem does not occur in: iCab
Blocks: 89557
->evaughan (who got pollmann's bugs)
Assignee: pollmann → evaughan
Taking this since I have a partial fix in my tree.
Assignee: evaughan → bzbarsky
Attached patch Proposed patch (obsolete) — Splinter Review
hyatt?  evaughan? reviews?
Keywords: patch, review
Target Milestone: --- → mozilla0.9.6
Attachment #54592 - Attachment is obsolete: true
Attachment #54593 - Attachment description: QA ONLY: Really ahcky UI for "Advanced" panel to test this patch (DO NOT EVER CHECK THIS ONE IN!) → QA ONLY: Really hacky UI for "Advanced" panel to test this patch (DO NOT EVER CHECK THIS ONE IN!)
Use NS_OK instead of returning a 'raw' 0.
This is for the nsrefcnt functions?  I was not sure whether those returned
nsresult or just a number (the new refcount, eg).
Comment on attachment 54698 [details] [diff] [review]
Better patch (a bit simpler and fewer member vars)

<sigh>.  Observer interfaces have changed.  new patch coming up.
Attachment #54698 - Attachment is obsolete: true
Attached file testcase to play with
What is the default value of the pref?  I assume we leave things alone by 
default, and only do the override if the user changes the pref?
Please make sure the pref is off and that the default behavior is unchanged 
when you land this. Thanks.
Can't we cache the prefBranch and thus avoid the costly work to get it again in
the destructor? I'm worried about slowing down the tear-down of IFRAMES even

We can certainly cache the prefBranch.  I wasn't sure what the
performance/footprint tradeoffs were here... It may well be better to cache the
prefBranch and _not_ cache the pref, getting it from the prefbranch instead as
needed (every call to GetBorderWidth, unfortunately).  Or we could cache both.

What do you think, Marc?
I think it is fine to cache the pref and the prefBranch - there are not
generally too many FrameFrames around, and the size of the added data members
are small, so I'm not worried about the footprint as much as the performance.
Comment on attachment 55839 [details] [diff] [review]
Patch that caches the pref branch

Attachment #55839 - Flags: superreview+
Checked in.
Closed: 23 years ago
Resolution: --- → FIXED
Was this preference disabled in Firefox 42 because it's no longer working. It was really useful.
Yes, this preference was removed in bug 1184842 because it was significantly complicating some optimizations that were being done to attribute setting.  See bug 1184842 comment 26 and bug 1184842 comment 33.
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.