6.0.0-git
2021-01-19

[#3504] iFrame block (external web page) wrong size
Summary iFrame block (external web page) wrong size
Queue Horde Base
Queue Version HEAD
Type Bug
State Resolved
Priority 1. Low
Owners
Requester tevans (at) tachometry (dot) com
Created 2006-02-18 (5449 days ago)
Due
Updated 2006-12-08 (5156 days ago)
Assigned 2006-08-07 (5279 days ago)
Resolved 2006-11-24 (5170 days ago)
Milestone
Patch No

History
2006-12-08 21:23:17 Jan Schneider Deleted Original Message
 
2006-12-08 21:21:01 Jan Schneider Comment #17 Reply to this comment
Committed, thanks.
2006-12-07 18:55:03 Chuck Hagenbuch Comment #16 Reply to this comment
cvs diff -u <filename>
2006-12-07 16:46:34 webmgr (at) muskingum (dot) edu Comment #15
New Attachment: iframe.php Download
Reply to this comment
Attached is a new iframe.php file with the preset sizes mentioned 
below, but they will display to the user as Small, Medium, Large, and 
Extra Large. This still seems a bit more intuitive, since most end 
users don't understand the concept of pixel sizes.



One of these days I'll make it easy and learn how to do the patch files.
2006-11-24 05:10:29 Chuck Hagenbuch Comment #14
State ⇒ Resolved
Reply to this comment
Functionality is working fine; we can reopen the ticket if there's 
actually a new patch.
2006-11-05 14:25:11 Jan Schneider Comment #13 Reply to this comment
Do you still have this on your agenda?
2006-08-22 15:55:28 Jan Schneider Comment #12 Reply to this comment
Sounds good.
2006-08-17 11:32:40 webmgr (at) muskingum (dot) edu Comment #11 Reply to this comment
Jan,

I completely agree... I might make such a change in my implementation 
today. If you agree that it makes sense, you are welcome to commit it.



tevans,

For the custom value, you could probably have the value trigger a 
javascript prompt similar to how Kronolith prompts for a New Category 
name, or Turba prompts for a distribution (contact) list name (could 
probably even recycle the code from Turba fairly easily).
2006-08-07 23:03:47 tevans (at) tachometry (dot) com Comment #10 Reply to this comment
We currently use this feature to render individual photographs and 
other images that tend to have a non-standard height dimension.



Any chance that the proposed list of preset height values could 
include "Custom" with an appropriate user input field when needed? 
That would provide a balance between usablility and flexibility.  I 
don't know whether a single portal block parameter could be configured 
to accept multiple input modes (select list AND text field).
2006-08-07 21:56:06 Jan Schneider Comment #9
State ⇒ Feedback
Reply to this comment
It would make even more sense then to give the labels names like 
"Small", "Medium", "Large".
2006-08-07 14:43:51 webmgr (at) muskingum (dot) edu Comment #8 Reply to this comment
I find it a little more helpful to have pre-determined heights in a 
drop-down list since the common user doesn't understand that height is 
a pixel measurement... nevermind what the heck a pixel is (in many 
cases).



That said: In my implementation, I changed the 'height' parameter of 
the iframe block as follows:



                                         'height' => array('type' => 'enum',

                                                                 'name' => _("Height"),

                                                                 'default' => '600',

                                                                 'values' => array('480' => _("480"),

                                                                         '600' => _("600"),

                                                                         '768' => _("768"),

                                                                        '1024' => _("1024"))));
2006-02-21 10:35:28 Jan Schneider Comment #7
State ⇒ Resolved
Reply to this comment
You are correct. Committed, thanks.
2006-02-21 00:35:00 tevans (at) tachometry (dot) com Comment #6 Reply to this comment
Agreed ... and I believe the patch meets your request. The outer 
condition tests to see whether the height parameter is empty (default) 
before checking the browser. If a value exists for the height 
parameter (the outer "else"), we will use it regardless of browser type.
2006-02-20 22:44:10 Jan Schneider Comment #5 Reply to this comment
One request: you shouldn't set the height depending on the browser. If 
the user sets a height, he should get it always.
2006-02-20 18:12:27 tevans (at) tachometry (dot) com Comment #4
New Attachment: iframe_block_patch[1].txt Download
Reply to this comment
Thanks for looking this over. I have updated the patch for CVS HEAD 
(rev. 1.23).
2006-02-18 10:44:03 Jan Schneider Comment #3 Reply to this comment
It works fine for me with Firefox, but I don't have any objections. 
You need to update the patch though, because Chuck changed the block 
code in the meantime.
2006-02-18 04:55:27 Chuck Hagenbuch Comment #2
State ⇒ Feedback
Reply to this comment
This seems like as reasonable a solution as any, I guess - any other thoughts?
2006-02-18 01:38:38 tevans (at) tachometry (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ iFrame block (external web page) wrong size
Queue ⇒ Horde Base
New Attachment: iframe_block_patch.txt
Reply to this comment
The portal block for viewing an external web page does not fill its 
enclosing table cell even though it has a height="100%" attribute. 
This is true for both IE and Firefox (I did not test any other 
browsers using multiple skins.



As a suggested fix/workaround/enhancement (take your pick), I wanted 
to suggest the attached patch. By adding an explicit height parameter 
to the iframe block, we can give the user better control over the 
portal layout. Some of our users have already given us positive 
feedback about this small change.



Thank you for your consideration.



Tom Evans

Tachometry

Saved Queries