March 2005 - Development - lists.drupal.org

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by Junyor 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/17343 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: njivy Updated by: Junyor Status: fixed Looks good in Opera and Safari now, thanks. The behavior of floats inside fieldsets is undefined in CSS, so it's not really that they're broken. They're just different. :) Junyor Previous comments: ------------------------------------------------------------------------ February 15, 2005 - 00:43 : njivy Attachment: http://drupal.org/files/issues/content_administration-Safari.jpg (33.21 KB) Using Safari 1.2.4 under OS 10.3, the form elements for content administration are not legible. (The path is "admin/node".) I am not enough of a CSS whiz to directly propose a solution. But I am willing to test patches. I attached a screenshot. ------------------------------------------------------------------------ February 15, 2005 - 15:43 : njivy Oops. Wrong version. ------------------------------------------------------------------------ February 25, 2005 - 02:31 : mathias This has been fixed [1]. [1] http://drupal.org/cvs?commit=13633 ------------------------------------------------------------------------ March 27, 2005 - 06:00 : adrian Attachment: http://drupal.org/files/issues/safari_error.jpg (11.03 KB) I just found the admin menu similarly messed up in the 4.6RC. I flushed my drupal.css just in case, but the bug definitely persist. ------------------------------------------------------------------------ March 27, 2005 - 09:10 : Junyor The same thing is happening in Opera. I tracked it down to having a floated object inside a fieldset. Firefox uses the fieldset as the containing block for the float, but Opera and Safari move the floated content outside of the fieldset. ------------------------------------------------------------------------ March 27, 2005 - 13:09 : Goba So then a container div might be a working solution. ------------------------------------------------------------------------ March 27, 2005 - 13:58 : adrian Attachment: http://drupal.org/files/issues/safari_float_render.diff (1.29 KB) Here is a patch that adds a break , with a class of 'clear' , and adds a .clear class to the drupal.css file. This is how I would fix it, but it's probably not semantically correct. But it does fix the problem.. ------------------------------------------------------------------------ March 27, 2005 - 13:58 : adrian err. and it's a patch. ------------------------------------------------------------------------ March 27, 2005 - 14:37 : adrian Attachment: http://drupal.org/files/issues/safari_float_render_0.diff (1.29 KB) I'm using the coffee defense as to why I missed the . infront of the .clear class ------------------------------------------------------------------------ March 27, 2005 - 14:45 : adrinux I can't see any other way to fix that, adding an ID and setting height on the fieldset would be just as ugly imo - maybe re-engineering the whole form would work but this isn't really the time to do that! Steven will moan at you for using a br probably :) ------------------------------------------------------------------------ March 27, 2005 - 16:54 : Steven The original commit referenced above did not fix the problem completely, it did make the node admin at least usable in Safari. Before, the form items would overlap eachother. Adrian's fix seems to work, and the br is sort of excusable in this case, as the browser's behaviour is quite broken with regard to fieldsets. Usually I use <span> to avoid nasty br issues in IE, but there don't seem to be any in this case. <br class="clear"> could be considered a CSS version of <br clear="both"> which is transitional XHTML. Commited to head.

1 0

[drupal-devel] [bug] Search watch "results" link is invalid
by TDobes 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/19535 Project: Drupal Version: cvs Component: search.module Category: bug reports Priority: normal Assigned to: TDobes Reported by: TDobes Updated by: TDobes Status: patch Attachment: http://drupal.org/files/issues/fix_search_watchdog_results_link.patch (771 bytes) Now that Drupal produces "friendly" search links, the old-fashioned search link being generated in watchdog messages no longer works. The attached patch updates it to follow the new syntax for search links (search/$type/$keys). Without this or a similar patch, these links are nonfunctional and confusing. TDobes

2 1

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by Steven 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/17343 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: njivy Updated by: Steven -Status: patch +Status: fixed The original commit referenced above did not fix the problem completely, it did make the node admin at least usable in Safari. Before, the form items would overlap eachother. Adrian's fix seems to work, and the br is sort of excusable in this case, as the browser's behaviour is quite broken with regard to fieldsets. Usually I use <span> to avoid nasty br issues in IE, but there don't seem to be any in this case. <br class="clear"> could be considered a CSS version of <br clear="both"> which is transitional XHTML. Commited to head. Steven Previous comments: ------------------------------------------------------------------------ February 15, 2005 - 00:43 : njivy Attachment: http://drupal.org/files/issues/content_administration-Safari.jpg (33.21 KB) Using Safari 1.2.4 under OS 10.3, the form elements for content administration are not legible. (The path is "admin/node".) I am not enough of a CSS whiz to directly propose a solution. But I am willing to test patches. I attached a screenshot. ------------------------------------------------------------------------ February 15, 2005 - 15:43 : njivy Oops. Wrong version. ------------------------------------------------------------------------ February 25, 2005 - 02:31 : mathias This has been fixed [1]. [1] http://drupal.org/cvs?commit=13633 ------------------------------------------------------------------------ March 27, 2005 - 06:00 : adrian Attachment: http://drupal.org/files/issues/safari_error.jpg (11.03 KB) I just found the admin menu similarly messed up in the 4.6RC. I flushed my drupal.css just in case, but the bug definitely persist. ------------------------------------------------------------------------ March 27, 2005 - 09:10 : Junyor The same thing is happening in Opera. I tracked it down to having a floated object inside a fieldset. Firefox uses the fieldset as the containing block for the float, but Opera and Safari move the floated content outside of the fieldset. ------------------------------------------------------------------------ March 27, 2005 - 13:09 : Goba So then a container div might be a working solution. ------------------------------------------------------------------------ March 27, 2005 - 13:58 : adrian Attachment: http://drupal.org/files/issues/safari_float_render.diff (1.29 KB) Here is a patch that adds a break , with a class of 'clear' , and adds a .clear class to the drupal.css file. This is how I would fix it, but it's probably not semantically correct. But it does fix the problem.. ------------------------------------------------------------------------ March 27, 2005 - 13:58 : adrian err. and it's a patch. ------------------------------------------------------------------------ March 27, 2005 - 14:37 : adrian Attachment: http://drupal.org/files/issues/safari_float_render_0.diff (1.29 KB) I'm using the coffee defense as to why I missed the . infront of the .clear class ------------------------------------------------------------------------ March 27, 2005 - 14:45 : adrinux I can't see any other way to fix that, adding an ID and setting height on the fieldset would be just as ugly imo - maybe re-engineering the whole form would work but this isn't really the time to do that! Steven will moan at you for using a br probably :)

1 0

[drupal-devel] [feature] Add links to examples in drupal docs
by rivena 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/19539 Project: Drupal Version: cvs Component: other Category: feature requests Priority: normal Assigned to: Anonymous Reported by: rivena Updated by: rivena Status: active As big a fan as I am of the API, there is one little thing I think could be easily improved (I think...what do I know ;p). I was looking at the hook documentation, and it says, for hook_access, 'For a detailed usage example, see node_example.module', but there is no link. You can't search for it, because it's not a function, so you have to go to files and find it. It's not horribly hard or anything, but how much nicer it would be if you could just click away. :) Anisa. rivena

1 0

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by adrinux 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/17343 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: njivy Updated by: adrinux Status: patch I can't see any other way to fix that, adding an ID and setting height on the fieldset would be just as ugly imo - maybe re-engineering the whole form would work but this isn't really the time to do that! Steven will moan at you for using a br probably :) adrinux Previous comments: ------------------------------------------------------------------------ February 14, 2005 - 23:43 : njivy Attachment: http://drupal.org/files/issues/content_administration-Safari.jpg (33.21 KB) Using Safari 1.2.4 under OS 10.3, the form elements for content administration are not legible. (The path is "admin/node".) I am not enough of a CSS whiz to directly propose a solution. But I am willing to test patches. I attached a screenshot. ------------------------------------------------------------------------ February 15, 2005 - 14:43 : njivy Oops. Wrong version. ------------------------------------------------------------------------ February 25, 2005 - 01:31 : mathias This has been fixed [1]. [1] http://drupal.org/cvs?commit=13633 ------------------------------------------------------------------------ March 27, 2005 - 05:00 : adrian Attachment: http://drupal.org/files/issues/safari_error.jpg (11.03 KB) I just found the admin menu similarly messed up in the 4.6RC. I flushed my drupal.css just in case, but the bug definitely persist. ------------------------------------------------------------------------ March 27, 2005 - 08:10 : Junyor The same thing is happening in Opera. I tracked it down to having a floated object inside a fieldset. Firefox uses the fieldset as the containing block for the float, but Opera and Safari move the floated content outside of the fieldset. ------------------------------------------------------------------------ March 27, 2005 - 12:09 : Goba So then a container div might be a working solution. ------------------------------------------------------------------------ March 27, 2005 - 12:58 : adrian Attachment: http://drupal.org/files/issues/safari_float_render.diff (1.29 KB) Here is a patch that adds a break , with a class of 'clear' , and adds a .clear class to the drupal.css file. This is how I would fix it, but it's probably not semantically correct. But it does fix the problem.. ------------------------------------------------------------------------ March 27, 2005 - 12:58 : adrian err. and it's a patch. ------------------------------------------------------------------------ March 27, 2005 - 13:37 : adrian Attachment: http://drupal.org/files/issues/safari_float_render_0.diff (1.29 KB) I'm using the coffee defense as to why I missed the . infront of the .clear class

1 0

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by adrian 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/17343 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: njivy Updated by: adrian Status: patch Attachment: http://drupal.org/files/issues/safari_float_render_0.diff (1.29 KB) I'm using the coffee defense as to why I missed the . infront of the .clear class adrian Previous comments: ------------------------------------------------------------------------ February 15, 2005 - 01:43 : njivy Attachment: http://drupal.org/files/issues/content_administration-Safari.jpg (33.21 KB) Using Safari 1.2.4 under OS 10.3, the form elements for content administration are not legible. (The path is "admin/node".) I am not enough of a CSS whiz to directly propose a solution. But I am willing to test patches. I attached a screenshot. ------------------------------------------------------------------------ February 15, 2005 - 16:43 : njivy Oops. Wrong version. ------------------------------------------------------------------------ February 25, 2005 - 03:31 : mathias This has been fixed [1]. [1] http://drupal.org/cvs?commit=13633 ------------------------------------------------------------------------ March 27, 2005 - 07:00 : adrian Attachment: http://drupal.org/files/issues/safari_error.jpg (11.03 KB) I just found the admin menu similarly messed up in the 4.6RC. I flushed my drupal.css just in case, but the bug definitely persist. ------------------------------------------------------------------------ March 27, 2005 - 10:10 : Junyor The same thing is happening in Opera. I tracked it down to having a floated object inside a fieldset. Firefox uses the fieldset as the containing block for the float, but Opera and Safari move the floated content outside of the fieldset. ------------------------------------------------------------------------ March 27, 2005 - 14:09 : Goba So then a container div might be a working solution. ------------------------------------------------------------------------ March 27, 2005 - 14:58 : adrian Attachment: http://drupal.org/files/issues/safari_float_render.diff (1.29 KB) Here is a patch that adds a break , with a class of 'clear' , and adds a .clear class to the drupal.css file. This is how I would fix it, but it's probably not semantically correct. But it does fix the problem.. ------------------------------------------------------------------------ March 27, 2005 - 14:58 : adrian err. and it's a patch.

1 0

[drupal-devel] orphaning marvin 2k for phptemplate
by Gabor Hojtsy 27 Mar '05

27 Mar '05

Hi, I am just announcing that I am not about to maintain marvin 2k for phptemplate anymore. I actually never maintained it, just done the port, since we needed it as a base for the drupal.hu theme we use. But after that I have no intention of dealing with possible issues surrounding the theme. In case anyone is interested, you can pick up the orphan project (or I can assign it to you, in case the future module maintainer has no site maintainer prviligedges to set himself as the module owner). http://drupal.org/project/marvin_2k_phptemplate Goba

1 0

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by adrian 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/17343 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: njivy Updated by: adrian -Status: active +Status: patch err. and it's a patch. adrian Previous comments: ------------------------------------------------------------------------ February 15, 2005 - 01:43 : njivy Attachment: http://drupal.org/files/issues/content_administration-Safari.jpg (33.21 KB) Using Safari 1.2.4 under OS 10.3, the form elements for content administration are not legible. (The path is "admin/node".) I am not enough of a CSS whiz to directly propose a solution. But I am willing to test patches. I attached a screenshot. ------------------------------------------------------------------------ February 15, 2005 - 16:43 : njivy Oops. Wrong version. ------------------------------------------------------------------------ February 25, 2005 - 03:31 : mathias This has been fixed [1]. [1] http://drupal.org/cvs?commit=13633 ------------------------------------------------------------------------ March 27, 2005 - 07:00 : adrian Attachment: http://drupal.org/files/issues/safari_error.jpg (11.03 KB) I just found the admin menu similarly messed up in the 4.6RC. I flushed my drupal.css just in case, but the bug definitely persist. ------------------------------------------------------------------------ March 27, 2005 - 10:10 : Junyor The same thing is happening in Opera. I tracked it down to having a floated object inside a fieldset. Firefox uses the fieldset as the containing block for the float, but Opera and Safari move the floated content outside of the fieldset. ------------------------------------------------------------------------ March 27, 2005 - 14:09 : Goba So then a container div might be a working solution. ------------------------------------------------------------------------ March 27, 2005 - 14:58 : adrian Attachment: http://drupal.org/files/issues/safari_float_render.diff (1.29 KB) Here is a patch that adds a break , with a class of 'clear' , and adds a .clear class to the drupal.css file. This is how I would fix it, but it's probably not semantically correct. But it does fix the problem..

1 0

[drupal-devel] [bug] illegible form elements for content administration (Safari)
by adrian 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/17343 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: njivy Updated by: adrian Status: active Attachment: http://drupal.org/files/issues/safari_float_render.diff (1.29 KB) Here is a patch that adds a break , with a class of 'clear' , and adds a .clear class to the drupal.css file. This is how I would fix it, but it's probably not semantically correct. But it does fix the problem.. adrian Previous comments: ------------------------------------------------------------------------ February 15, 2005 - 01:43 : njivy Attachment: http://drupal.org/files/issues/content_administration-Safari.jpg (33.21 KB) Using Safari 1.2.4 under OS 10.3, the form elements for content administration are not legible. (The path is "admin/node".) I am not enough of a CSS whiz to directly propose a solution. But I am willing to test patches. I attached a screenshot. ------------------------------------------------------------------------ February 15, 2005 - 16:43 : njivy Oops. Wrong version. ------------------------------------------------------------------------ February 25, 2005 - 03:31 : mathias This has been fixed [1]. [1] http://drupal.org/cvs?commit=13633 ------------------------------------------------------------------------ March 27, 2005 - 07:00 : adrian Attachment: http://drupal.org/files/issues/safari_error.jpg (11.03 KB) I just found the admin menu similarly messed up in the 4.6RC. I flushed my drupal.css just in case, but the bug definitely persist. ------------------------------------------------------------------------ March 27, 2005 - 10:10 : Junyor The same thing is happening in Opera. I tracked it down to having a floated object inside a fieldset. Firefox uses the fieldset as the containing block for the float, but Opera and Safari move the floated content outside of the fieldset. ------------------------------------------------------------------------ March 27, 2005 - 14:09 : Goba So then a container div might be a working solution.

1 0

[drupal-devel] [bug] Konqueror 3.3.x problems with forms input inside fieldset tags
by stefan nagtegaal 27 Mar '05

27 Mar '05

Issue status update for http://drupal.org/node/16729 Project: Drupal -Version: 4.5.2 +Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: syscrusher Updated by: stefan nagtegaal Status: active I can verify that this works flawlesly with drupal 4.6 and any Mac browser.. It would be nice if this would be applied.. stefan nagtegaal Previous comments: ------------------------------------------------------------------------ February 4, 2005 - 06:33 : syscrusher Certain versions of the Konqueror browser have a serious problem with form input in Drupal 4.4.x and 4.5.x. The symptoms are that keyboard and mouse input is completely ignored in the affected "text" and "textarea" fields. The symptoms only occur on textual fields that occur within a <fieldset>...</fieldset> tag set. This occurs, for example, when the form_group() API function is invoked. I have tested several variants on the fieldset attributes, and as far as I can tell it doesn't matter what attributes are applied. I also tried it with a manually-created <fieldset><input type="text" ... /></fieldset> sequence, to eliminate the subtags such as legend, description, and title. The problem occurs even with a bare fieldset, and immediately goes away when the form elements are used without being in a fieldset. I further tested to ensure that the <table> tag was not involved, because a Google search suggested that there were problems with tables and fieldsets in Konqueror. Again, the problem is duplicable with no table in the fieldset. It took a lot of digging, but I have finally traced the problem to the file misc/drupal.css. Specifically, the following clause appears to be at fault: .node-form fieldset { display: inline; } If I comment out the "display: inline;" attribute, then the fields work correctly. There does not appear to be any ill effect from this so far, but I haven't tested extensively nor have I tested to see if this patch breaks any other browsers. I can duplicate this problem across several patch levels of Konqueror 3.3.0, and across Drupal 4.5.0 through 4.5.2. ------------------------------------------------------------------------ February 4, 2005 - 07:14 : syscrusher I've verified that the patch doesn't break Firefox 1.0, and also that it /does/ fix the problem with Konqueror 3.3.0 in Drupal 4.4, on one of my production sites. Incidentally, the problem doesn't occur with older Konqueror versions, as far as I can tell. ------------------------------------------------------------------------ March 26, 2005 - 20:15 : Steven I believe that piece of CSS is there for IE5, but I can't remember if it was for Windows or Mac. I'll do some testing later. ------------------------------------------------------------------------ March 26, 2005 - 21:00 : Junyor Works fine in Safari and Opera with or without that rule. IE 5 seems to have the same problem with or without it. In 4.5.2, the fieldsets aren't displayed at all. In HEAD, they cross the screen, pushing everything else down. In other words, it doesn't seem to have any bad effects on Mac browsers with or without that rule. ------------------------------------------------------------------------ March 26, 2005 - 21:09 : syscrusher BTW, I can also duplicate this bug with the CVS version of Drupal 4.6 as of 2005-03-24.

1 0