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.

[Christian Boos]

defaults and tickets column are missing; browser is IE8

[Christian Boos]

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

[Remy Blank]

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.

[Remy Blank]

Permissions panel with Firefox

[Remy Blank]

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?

[Christian Boos]

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;

[Christian Boos]

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          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

[Remy Blank]

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).

[Remy Blank]

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

[Remy Blank]

(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.

[Christian Boos]

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

[Mikael Relbe]

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?

[Remy Blank]

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

[Itamar Oren]

Permission admin overlap with Firefox 3.6.10 on 1366x768 screen

[Itamar Oren]

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…

[Itamar Oren]

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…

[Christian Boos]

Sure, we can reconsider this.

[Remy Blank]

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.

[Christian Boos]

I'd like to revisit this issue (which is still not satisfyingly solved), by adopting the following layout:

Replying to 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          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

See repos:cboos.git:ticket8866/take2 (visible in action in demo-0.13 for those having admin rights there).

It's not 100% finalized, as there's still some overlap between the two .addnew panels in the permission panel, but I'll eventually get there.

[Christian Boos]

Replying to cboos:

… there's still some overlap between the two .addnew panels in the permission panel

I found a way to fix the overlap problem, see rebased and completed branch repos:cboos.git:ticket8866/take2-r11150.

I'd like to get this in 1.0, so feedback welcome.

[Christian Boos]

Replying to cboos:

I found a way to fix the overlap problem, see rebased and completed branch repos:cboos.git:ticket8866/take2-r11150.

Now visible on demo-0.13 (for people who have TRAC_ADMIN there, of course).

[Remy Blank]

Replying to cboos:

Now visible on demo-0.13 (for people who have TRAC_ADMIN there, of course).

That is… not me :( Ok, fixed now.

I'm afraid I don't like the new layout. Most of the admin pages have only a single "Add…" panel, and therefore have a large block of white space above the table, and the interesting data is pushed down unnecessarily. Moreover, on "normal" screens, the table becomes overly wide, which is not useful for most admin pages (i.e. all ticket admin pages).

It would be fine if the new layout appeared for narrow screens only, and the old layout remained when the table fits next to the panels, but AFAIK this kind of re-flow isn't possible with CSS alone. So we're basically optimizing for the rare case (narrow screen) while making the common case less functional and not so good-looking (IMO, of course).

I would prefer keeping the current layout.

(OT, while I see it: are you very attached to the text shadows on buttons? I find they make the text fuzzy and less readable. But if you prefer keeping them, I'll remove them locally here.)

[Christian Boos]

Replying to rblank:

Replying to cboos:

Now visible on demo-0.13 (for people who have TRAC_ADMIN there, of course).

That is… not me :( Ok, fixed now.

I'm afraid I don't like the new layout. Most of the admin pages have only a single "Add…" panel, and therefore have a large block of white space above the table, and the interesting data is pushed down unnecessarily.

It's not unnecessarily, the very purpose to push the data down is to fix the issue raised in this ticket, i.e. the truncation of the content of the table due to the presence of (even one) .addnew float on the right. This is still a serious problem I think:

• attachment:milestones-truncated.png​, width at 1237px
• attachment:plugins-truncated.png​, width at 1603px

Not exactly narrow, even if you take out the grey borders specific to t.e.o.

Now I agree that for the other panels like the ticket enums, the whitespace at the top is probably too big.

An alternative would be to place the .addnew below the table, it would also fix the issue and avoid pushing the table down.

Moreover, on "normal" screens, the table becomes overly wide, which is not useful for most admin pages (i.e. all ticket admin pages).

I suppose this can be fixed… and maybe the .addnew panel would just move up when there's some space left. I'll try harder.

It would be fine if the new layout appeared for narrow screens only, and the old layout remained when the table fits next to the panels, but AFAIK this kind of re-flow isn't possible with CSS alone. So we're basically optimizing for the rare case (narrow screen) while making the common case less functional and not so good-looking (IMO, of course).

(OT, while I see it: are you very attached to the text shadows on buttons? I find they make the text fuzzy and less readable. But if you prefer keeping them, I'll remove them locally here.)

Well, yes I like them. For me, the text is not fuzzy but looking between normal and bold (if you have a screenshot I'm interested; maybe it only looks good for me on Windows ;-) ).

[Christian Boos]

milestones admin panel at r11154, screen width of 1237px

[Christian Boos]

plugins admin panel at r11154, screen width of 1603px

[Remy Blank]

Never mind, then. But please, whatever solution you end up keeping, please allow reverting it with CSS only. It should not be necessary to write a Genshi template (and therefore lose in performance) if I choose readability over fanciness.

[Remy Blank]

Wait, here's a different idea. How about making the "add panels" more rectangular than square? This would allow a layout like the following:

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

It would require putting edit files and possibly labels on the same line, for example:

+- Add component ----------------------------------------+
+ Name: |_____________|  Owner: |_____________|  | Add | |
+--------------------------------------------------------+

This would make better user of the available space, and scale better when the number of panels increases (not that we expect much more than 2-3, but still). And yeah, no big white empty space :)

[Christian Boos]

I experimented a bit further and managed to get the "usual" layout when the window is wide enough, and the "stacked" layout otherwise. In the latter situation, we don't have that much whitespace left, as it happens only for narrow window widths.

There are still a few issues left, described in the commit log:

• [099db1c6/cboos.git] #8866: the normal/wide window situation regains the original layout

I'm not sure yet why there's such a difference between Chrome/Safari and the other browsers and if I'll be able to "fix" it for them.

[Remy Blank]

Quick and dirty prototype implementing comment:40.

[Remy Blank]

8866-addnew-top-r11161.patch​ demonstrates what I meant in comment:40. It's implemented as a quick hack, for testing the ticket admin pages, but the same effect can be applied in the other panels. What I especially like is the straightforward layout, the available space is used well, and there's no "magic" jumping around on resize

I just wanted to get some feedback before implementing (or not) the whole thing cleanly. In particular, I'll need to reorganize some elements in the plugins and permissions panels, and I will create a class separate from .addnew for the new layout to avoid breaking plugins that use the old layout (e.g. ​AccountManagerPlugin).

Thoughts?

[Christian Boos]

Replying to rblank:

8866-addnew-top-r11161.patch​ demonstrates what I meant in comment:40. It's implemented as a quick hack, for testing the ticket admin pages, but the same effect can be applied in the other panels. What I especially like is the straightforward layout, the available space is used well, and there's no "magic" jumping around on resize

Yes, this looks indeed better than I thought. I think we should dig further in this direction, as I didn't get any insight about why the behavior of my approach is so broken with non-WebKit browsers. Even there we have the "jump" effect, which is probably not optimal.

I just wanted to get some feedback before implementing (or not) the whole thing cleanly.

We'll need to structure the fieldsets a bit more, because a mere display: inline is not really good: depending on the width, you can end up with, e.g.

Name: __________________ Due:
_____________________  Format: MMM d, yyyy h:mm:ss a 
[Add]

We need to make sure the label and its input field always stay on the same line.

In particular, I'll need to reorganize some elements in the plugins and permissions panels, and I will create a class separate from .addnew for the new layout to avoid breaking plugins that use the old layout (e.g. ​AccountManagerPlugin).

It depends… if the new style could just fit on the existing .addnew panels provided by plugins, that would be better. So maybe do that rename step last, so that we can play around with the plugins first.

[Remy Blank]

Replying to cboos:

We'll need to structure the fieldsets a bit more, because a mere display: inline is not really good

Sure, as I said it was only a quick hack to show what I meant.

We need to make sure the label and its input field always stay on the same line.

Yes, that's fairly easy to achieve, especially when the <input> is nested in the <label>.

It depends… if the new style could just fit on the existing .addnew panels provided by plugins, that would be better. So maybe do that rename step last, so that we can play around with the plugins first.

I'll try. I thought that ​AccountManagerPlugin used tables in the "Add …" panels, but that's actually wrong, so it may just work. The plugins and permissions pages will require structural changes, but there it doesn't matter because they use different classes and it's unlikely that a plugin used them.

[Remy Blank]

Proper implementation of .addnew panels at the top

[Remy Blank]

This turned out pretty well, I think. 8866-addnew-top-r11163.patch​ implements the ".addnew panels at the top" variant properly. Field labels and hints are kept with the field when wrapping, and all admin panels look good in all browsers (even IE7, I stole your trick for display: inline-block). Even ​AccountManagerPlugin looks good, although it could look even slightly better if it moved the help text after the button, as I did for our panels. I left a rule to set <br/> to display: none even though I removed the tags, in the hope that it will make plugins using the .addnew class look better.

Thoughts?

[Christian Boos]

Great! I like it.

I'd perhaps just add:

trac/htdocs/css/admin.css

@@ -60 +60 @@
  padding: 0.2em 0.5em 0.2em 0;
  white-space: nowrap;
 }
+form.addnew div.buttons { float:right; }
 form.addnew div.buttons input { margin: 0 0.5em 0 0; }
 form.addnew p.hint,
 form.addnew span.hint {

[Remy Blank]

Replying to cboos:

I'd perhaps just add:

Mmh… That makes the forms with few controls (e.g. "Priorities") look weird on a wide screen, with the input at the far left and the button at the far right. Also, we tend to have buttons left-aligned (this page, the wiki, milestones, etc.). So I'd rather do without.

Patch committed in [11164].

That was the last open ticket for 1.0 (except for the translation stuff). How about releasing 1.0beta1 this week-end?

[Jun Omae]

When the button in .addnew panels is pushed, the layout is disarranged by the margins for the button. The style is from .buttons input[type=submit]:active.

[1786a767/jomae.git] for the issue.

[Christian Boos]

Good catch! However I also had the idea to revisit how this particular effect was achieved, using position: relative perhaps (nothing concrete yet).

[Remy Blank]

Heh, funny effect :)

[Jun Omae]

Replying to cboos:

Good catch! However I also had the idea to revisit how this particular effect was achieved, using position: relative perhaps (nothing concrete yet).

[14f0d06a/jomae.git] uses position: relative. I confirmed with IE 7-8, Firefox 14, Chrome 21 beta and Opera 12.

I think it would be simple and a small impact on other forms (e.g. is provided by plugins) than adjusting the button margins.

[Christian Boos]

Replying to jomae:

Replying to cboos:

Good catch! However I also had the idea to revisit how this particular effect was achieved, using position: relative perhaps (nothing concrete yet).

[14f0d06a/jomae.git] uses position: relative. I confirmed with IE 7-8, Firefox 14, Chrome 21 beta and Opera 12.

I think it would be simple and a small impact on other forms (e.g. is provided by plugins) than adjusting the button margins.

Yes, perfect! Please commit.

[Jun Omae]

Applied in [11195]. Thanks.

[Ryan J Ollos]

In [12952], removed CSS rule that is unused after [11164]. Merged in [12953].