Admin pages messed up with browsers other than IE

[jouvin@…]

Hi,

I upgraded to recent trunk revision (8858, then 8872). In these versions, admin page layout is completely messed up when using a browser other than IE. This is the case for example for Ticket->milestones, and General->permissions: the area to enter new information overlap the list of existing entries.

[cboos]

defaults and tickets column are missing; browser is IE8

[cboos]

Confirmed, this is not really optimal for narrow screens.

[jouvin@…]

I should have said I did all my test on a screen 1280x800. I tested IE8, Firefox, Opera and Chrome. It works properly only in IE8.

Michel

[rblank]

You should have a scrollbar at the bottom of the table that allows seeing the hidden portions of the table. While not ideal, it's better than what we had before, namely that the "new item" boxes were overlapping the table transparently, with no way to access the overlapping part. The new behavior was introduced in [8246] on 0.11-stable.

The screenshot shows a very narrow view, about 500px. This is not a narrow screen, it's a very narrow screen ;-)

Anyway, better ideas welcome.

[jouvin@…]

Screen capture of messed up display with Opera 10

[anonymous]

Replying to rblank:

You should have a scrollbar at the bottom of the table that allows seeing the hidden portions of the table. While not ideal, it's better than what we had before, namely that the "new item" boxes were overlapping the table transparently, with no way to access the overlapping part. The new behavior was introduced in [8246] on 0.11-stable.

It seems I'm still getting what you call "old behaviour" (it was working fine in fact with r7799, the last revision I used before upgrading to r8858), as you can see in the screen shot. It was made with Opera but I get exactly the same result with Firefox and Chrome. Only IE8 works for me.

[rblank]

Permissions panel with Firefox

[rblank]

That's weird, I have the correct behavior here with Firefox 3.0.14 and r8872 (see attachment:firefox-permissions.png​) and Opera 10.10.

The changes were done to the stylesheets. Could it be that your browsers still cache the old stylesheet? Try a Shift+reload or emptying the cache to make sure. Also, do you have any custom stylesheets in your environment?

[cboos]

Also, if you have done a trac-admin ... deploy ... and used htdocs_location, you need to re-deploy again (we should make TracUpgrade more explicit about the need to do that after every upgrade).

[jouvin@…]

I never used trac-admin deploy and htdocs_location is blank in my trac.ini. So I don't think this is the pb here. Nevertheless I tried a deploy and defining htdocs_location to the resulting directory and I lost my css... I never had such a pb so far so I am not sure this is the reason.

Clearing the browser cache doesn't help too...

[jouvin@…]

More on the original issue...

I identified that this is a conflict with the project-specific CSS I use to define formatting of headings... The pb happens with all projects with such a CSS defined. It doesn't happen for one project where the CSS (for some unknown reason...) is ignored since the project was created (a while ago).

Still diging...

[anonymous]

I identified the culprit in my poject-specific css (that I use for many years...):

h1
{

margin-top: 1em;

}

Removing margin-top attribute restores the normal behaviour... I still have to find the reason and why it is working properly with IE8 (it seems that for some attributes IE is not implementing inheritance where other browsers do, I don't know if this may be the cause...).

[jouvin@…]

Here is the end of the story... It really seems that browsers (except IE) have a problem to correctly size the "revokeform" from (in the middle) if the top marging of the h1 and h2 (both displayed at the top of the page) are not identical. The workaround I implemented is to add to my project-specific CSS:

.admin h1 { margin-top: 0; }

Probably, the easiest would be to put it in the standard admin.css to ensure that whatever is defined by default for h1 margin-top, this doesn't affect how the admin pages are displayed.

[Michel Jouvin <jouvin@…>]

Is it possible to get the proposed patch merged into the trunk or explicitly rejected?

--- lib/python2.4/site-packages/Trac-0.12dev_r8912-py2.4.egg/trac/htdocs/css/admin.css.r8912    2009-12-16 08:45:00.000000000 +0100
+++ lib/python2.4/site-packages/Trac-0.12dev_r8912-py2.4.egg/trac/htdocs/css/admin.css  2009-12-16 08:42:54.000000000 +0100
@@ -1,3 +1,9 @@
+/*
+ Patch proposed by Michel Jouvin <jouvin@lal.in2p3.fr> to fix a potential
+ problem with all browsers. See ticket #8866.
+*/
+.admin h1 { margin-top: 0; }
+
 #content.admin h1 { float: left; }
 
 #tabs { background: #f7f7f0; border: 1px solid black;

[cboos]

I think the change proposed in the patch doesn't harm but I haven't tested it yet. We keep an eye on it and I (or Remy) will later integrate it or not, depending on our testing.

The more general issue about this ticket is that we need to find a general way to make the admin panels work well on narrow windows.
I'd like to see something like this:

+---+ +----------------+ +-----+
|idx| | table          | |add  |
|   | |                | |panel|
|   | |                | +-----+
|   | |                |
+---+ |                |
      |                |
      +----------------+

on wide windows (as it is now),
and:

+---+            +-----+
|idx|            |add  |
|   |            |panel|
|   |            +-----+
|   | +----------------+
+---+ | table          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

for narrow windows, but the CSS for this is not trivial (or I wasn't able to find the correct pick yet).

[Michel Jouvin <jouvin@…>]

I understand your point for the final goal but I think it should not prevent to integration of the proposed change at least as a temporary step as the current CSS just doesn't work if you have defined a margin-top in your project-specific CSS. IMO there is nothing wrong in doing that and you should expect not to break anything. Trac core CSS should protect themselves against side effect of site modifications.

Because the current CSS is in fact unusable, I raised the priority to high... and I think it is really! Fixing this particular issue should not prevent further refactoring along the lines you said (but I am not completely sure it's doable on the basis of my CSS expertise, limited I must admit). Even if you succeed implementing what you propose, you'll have to get working properly in the context that was the source of this ticket!

[Michel Jouvin <jouvin@…>]

A comment on my proposed patch. I think that to fully address the problem with all browsers (except IE8) when h1 and h2 margin-top are inconsistent, the patch should define both to a consistent default value (0) that can be modified anyway by the site later on. Thus my proposed patch is:

+/*
+ Patch proposed by Michel Jouvin <jouvin@lal.in2p3.fr> to fix a potential
+ problem with all browsers. See ticket #8866.
+*/
+.admin h1 { margin-top: 0; }
+.admin h2 { margin-top: 0; }
+
 #content.admin h1 { float: left; }
 
 #tabs { background: #f7f7f0; border: 1px solid black;
@@ -20,7 +27,7 @@
 }
 
 #tabcontent { padding: 0.4em 0 0.4em 2em; margin-left: 12em; min-height: 300px; }
-#tabcontent h2 { color: #333; margin-top: 0; }
+#tabcontent h2 { color: #333; }
 #tabcontent form { overflow: auto; padding: 0 1px; }
 p.help { color: #666; font-size: 90%; margin: 1em .5em .5em; }
 

Not that the current definition for h2 in fact works because the first h2 used in the context of #tabcontent but IMO may be a source of future problem in case some h2 appears before #tabcontent.

[Michel Jouvin <jouvin@…>]

Replying to cboos:

The more general issue about this ticket is that we need to find a general way to make the admin panels work well on narrow windows.
I'd like to see something like this (on narrow windows):

+---+            +-----+
|idx|            |add  |
|   |            |panel|
|   |            +-----+
|   | +----------------+
+---+ | table          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

In fact, about the proposal for narrow windows, I'd suggest this small variation when there are several add panels (like for permissions) if it fits:

+---+    +-----+ +-----+
|idx|    |add  | |add  |
|   |    |panel| |panel|
|   |    +-----+ +-----+
|   | +----------------+
+---+ | table          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

[rblank]

Replying to Michel Jouvin <jouvin@…>:

In fact, about the proposal for narrow windows, I'd suggest this small variation when there are several add panels (like for permissions) if it fits:

I'd be very interested in seeing how this can be achieved using HTML and CSS alone (i.e. having panels on the side if the table fits, on the top if it doesn't).

[rblank]

I'll try to reproduce and fix the initial issue, but this shouldn't block 0.12.

[rblank]

(Forgot to change the milestone)

[Carsten Klein <carsten.klein@…>]

sample html and css for the new layout

[Carsten Klein <carsten.klein@…>]

see the attached sample html + css for a semi-working layout

please note that the order of .admin-panel and .panel and .tab-content is important, otherwise .panel will float below .tab-content

[Carsten Klein <carsten.klein@…>]

the problem is though, that it will not render the two .panels below each other when there is enough space for all three (.admin-panel, .tabcontent and .panel) to be rendered side by side. perhaps you will find a solution to this.

[Carsten Klein <carsten.klein@…>]

i think we should stick with float:left for all inside #content so that even on small displays the content does not overlap and layouts adaptively.

however, as of now, at least 800x600 should be possible on so-called netbooks.

resolutions below that should cope with what is available, IMO.

but remove the fixed size on #content unless reestablished by a user provided site.html and associated css.

[cboos]

See also #9225 screenshots for a reminder of the old buggy behavior in 0.11.

[mrelbe]

I've seen the symptom demonstrated in attachment:snapshot_git_trac_problem.jpg:ticket:9225​

In my case, I resolved the problem by shrinking the size of the font of the "Administration" header so that its width didn't exceed the width of the left panel beneath it -- that trick made the whole page render fine. (As I remember this, this was browser-indendepent, i.e. same result in any browser before and after the "fix".)

Perhaps a clue to the root cause?

[Carsten Klein <carsten.klein@…>]

Replying to mrelbe:

Perhaps a clue to the root cause?

fixed size on #content and inner elements exceeding that size causing it to overflow?

[rblank]

Postponing until a patch implementing better behavior for the side panels is proposed.

[itamaro]

Permission admin overlap with Firefox 3.6.10 on 1366x768 screen

[itamaro]

Just wanted to note that I get the overlapping behavior with Firefox 3.6.10 on a 1366x768 screen (see screenshot​ (using the t.e.o site.html and css).

Maybe I can get someone who knows his ways with CSS to take a look at it...

[itamaro]

Also interesting to note that when I view the attachment I've added, the adsense-bar on the right floats above (and hides) the part of the image that extends beyond the content-boundary.

[Michel Jouvin <jouvin@…>]

Replying to itamaro:

Just wanted to note that I get the overlapping behavior with Firefox 3.6.10 on a 1366x768 screen (see screenshot​ (using the t.e.o site.html and css).

Maybe I can get someone who knows his ways with CSS to take a look at it...

This is clearly the problem caused by the margin inconsistencies described in my previous comment. Have you tried the workaround proposed in #comment14 ?

[Michel Jouvin <jouvin@…>]

I tried to answer #comment25 but my answer is considered as SPAM... I'll try to put it in an attachment...

[Michel Jouvin <jouvin@…>]

Replying to Michel Jouvin <jouvin@…>:

I tried to answer #comment25 but my answer is considered as SPAM... I'll try to put it in an attachment...

I really don't understand why the workaround I proposed has not been integrated into 0.12 until a definitive fix is available solving all known issues... As shown by previous replies, the current problem caused by different margin-top for h1 and h2 makes some admin panels unusable and this has nothing to do with the window/screen size. I think the proposed workaround should have a side effect close to 0 and a site really wanting a non zero margin-top will still be able to implement it in a site CSS. At least, the 0 margin should not prevent admin panels to be usable...

[cboos]

Sure, we can reconsider this.

[rblank]

Patch from comment:25 verified and applied in [10369]. I'm closing this ticket, as the initial issue is fixed. For layout improvements, please open a new ticket.