Last modified: 2011-03-13 18:06:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8175 - User preference to disable frame-breakout code
User preference to disable frame-breakout code
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-06 20:05 UTC by Marco
Modified: 2011-03-13 18:06 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to do it. (1.68 KB, patch)
2006-12-07 17:27 UTC, Marco
Details
nowhere else located (1.55 KB, text/plain)
2006-12-07 17:38 UTC, Marco
Details
New version (1.54 KB, patch)
2006-12-07 17:40 UTC, Marco
Details
full patch (3.10 KB, patch)
2006-12-07 18:00 UTC, Marco
Details

Description Marco 2006-12-06 20:05:05 UTC
Current, the iframe protection is not overridable.
Can it be changed in a way that it can be disabled for a specific user via
monobook.js via including...let's say a variable "var
disable_iframe_protection=true;"?

Regards,
Marco
Comment 1 Brion Vibber 2006-12-06 21:17:46 UTC
This would I think require moving the frame breakout to run later, say after
body load rather than during the script.
Comment 2 Marco 2006-12-06 21:19:18 UTC
I heard it is located in wikibits.js. Why not just move the wikibits.js
inclusion after user/monobook.js inclusion?
Comment 3 Brion Vibber 2006-12-06 21:28:02 UTC
Then things run from monobook.js would not work due to uninitialized variables
and missing functions.
Comment 4 Marco 2006-12-07 16:07:52 UTC
Why not create a JS called "frame.js" and including only this after monobook?
Comment 5 Marco 2006-12-07 17:27:32 UTC
Created attachment 2832 [details]
Patch to do it.

Added skins/common/frame.js
Changed skins/MonoBook.php and skins/common/wikibits.js
Comment 6 Rob Church 2006-12-07 17:30:27 UTC
1. "Cutted out" isn't proper English; if you're going to comment there, or
anywhere else, do it properly. I don't personally think you *need* those comments.
2. You need to include frame.js in more skins than just Monobook.
Comment 7 Marco 2006-12-07 17:31:30 UTC
(In reply to comment #6)
> 1. "Cutted out" isn't proper English; if you're going to comment there, or
> anywhere else, do it properly. I don't personally think you *need* those comments.
OK.
> 2. You need to include frame.js in more skins than just Monobook.
*doing*
Comment 8 Marco 2006-12-07 17:38:25 UTC
Created attachment 2833 [details]
nowhere else located

grep doesn't find any inclusion of wikibits.js in whole skin directory
Comment 9 Marco 2006-12-07 17:40:19 UTC
Created attachment 2834 [details]
New version
Comment 10 Marco 2006-12-07 18:00:23 UTC
Created attachment 2835 [details]
full patch

Now really all I could find is replaced.
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-07 22:40:22 UTC
Non-Monobook skins use the reference in includes\Skin.php.
Comment 12 Brion Vibber 2006-12-08 00:13:58 UTC
Avoid adding another file; that means yet another
HTTP hit on first page view, slowing down the
user experience.

There's already a system in place to add functions
to run on body load, better to hook into that.
Comment 13 Tim Starling 2006-12-08 06:58:50 UTC
Fixed in r18220.
Comment 14 Marco 2006-12-08 13:18:41 UTC
As I can see, a user (a normal wikipedia user) can't decide if he can put off
the frame protection for himself only. This is very useful for things like the
Interwiki-Linkchecker and browser-based anti vandal tools which display diffs in
framesets.
Comment 15 Rotem Liss 2006-12-08 13:48:48 UTC
(In reply to comment #14)
> As I can see, a user (a normal wikipedia user) can't decide if he can put off
> the frame protection for himself only. This is very useful for things like the
> Interwiki-Linkchecker and browser-based anti vandal tools which display diffs in
> framesets.

Please open another bug. This bug is fixed.
Comment 16 Rotem Liss 2006-12-08 13:50:39 UTC
I probably didn't read properly. The fix was about an option on
LocalSettings.php; this bug is about a user preference. Reopening for now.
Comment 17 Rob Church 2006-12-09 10:13:35 UTC
Changed summary, though I'm not sure we really want this at a user level.
Comment 18 Rob Church 2007-06-11 07:08:51 UTC
There's now a site-wide configuration option, $wgBreakFrames, which I think is much more useful than having this kind of thing selectable at a user preference level, since "frame breaking" is intended to combat hotlinking, which registered users aren't likely to do.

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


Navigation
Links