Unexpected behavior of the Categories meta box

[linuxologos]

The "All Categories" tab in "Categories" meta box on Add New Post screen does not float in the right place (by some pixels to the top), if single-column screen layout is chosen.

Tested against latest trunk, IE/Firefox/Chrome Windows, Firefox Linux.

It's new in 3.3, probably caused by #18198 or #18314.

See also screenshot.

[linuxologos]

Actually, it's more complicated...

Go to Add New Post screen. The default choice is two-columns screen layout.

In WP 3.3 the Categories meta box has only one tab (All Categories). In 3.2.1 there is a Most Used tab, too. I don't know if this change is by design.

Now in WP 3.3, drag & drop the Categories meta box from the right to the left (wider) column. The Most Used tab suddenly appears and both tabs are in the right place (and the original bug described here is invalidated!).

[linuxologos]

After a dipper look, some more evidence:

Both in WP 3.2.1 and 3.3 the "Most Used" tab in Categories meta box gets the hide-if-no-js class. Difference is, in WP 3.3 it matches against

#side-sortables .category-tabs li.hide-if-no-js {
    display: none;
}

and it's hidden. Of course, it shouldn't. (Same browser window.)

If you drag & drop (in WP 3.3) the Categories meta box from the right to the left (wider) column, the Most Used tab appears, because the parent div has now the #normal-sortables id and the earlier match doesn't apply.

Also in WP 3.3, meta boxes which are in the right column before the screen layout switch (from two- to one-column) retain the #side-sortables parent div, which is correct, but it causes the floating problem initially described (another CSS problem?).

If Category meta box is already in the left column before the screen layout switch, nothing changes, as expected.

[linuxologos]

The above mentioned CSS rule doesn't seem to exist in WP 3.2.1 at all. If it was inserted in WP 3.3 at some point and it isn't useful anymore, the patch removes it and reveals the "Most Used" tab.

[duck_]

The rule exists to hide the Most Used tab when Javascript is disabled, but it's not written correctly. See [18668], #16810 and #18656.

Attached 19129.2.patch​ to correctly display none when the body element has the .no-js class. Also does not restrict this to #side-sortables.

[duck_]

Replying to duck_:

Also does not restrict this to #side-sortables.

Actually it does need to specify #side-sortables otherwise the display: inline rule still has more specificity. Re-uploaded.

[duck_]

In [19179]:

Only hide "Most Used" category tab when the body has .no-js class. See #16810, fixes #19129.

[linuxologos]

Replying to linuxologos:

Also in WP 3.3, meta boxes which are in the right column before the screen layout switch (from two- to one-column) retain the #side-sortables parent div, which is correct, but it causes the floating problem initially described (another CSS problem?).

If Category meta box is already in the left column before the screen layout switch, nothing changes, as expected.

This doesn't exist in WP 3.2.1, because all meta boxes get the #normal-sortables parent div, when switching to single-column layout.

See new screenshot and patch, which tries to cure this.

[linuxologos]

19129.4.patch​ touches only #side-sortables .category-tabs li, which clearly affects the Add New Post screen.

#side-sortables .add-menu-item-tabs li (Appearance > Menus screen) and .wp-tab-bar li do not seem to appear on this screen and I don't know if they should be affected, as of 19129.3.patch​.

[duck_]

Replying to linuxologos:

Sorry didn't notice that part. I think that in 3.2 the switch to 1 column moved the boxes out of #side-sortables. This isn't done in 3.3 to help with responsive admin, so as the screen expands the boxes in 1 column can move out into the side automatically.

[linuxologos]

Everything is fine, except for the fact that even after moving the meta box to the left (wider) column, the below rule

#side-sortables .category-tabs li {
	display: inline;
}

is still in action, causing the tabs, which are now vertically aligned, to collapse upon each other.

That was really the original ticket about. 19129.4.patch​ offers a solution to this, if it's good to go.

The JS stuff came in later, but was solved first. :)

[duck_]

Re-assigning to azaozz as this is a responsive follow up issue.

[azaozz]

Replying to duck_:

Re-assigning to azaozz as this is a responsive follow up issue.

Was this fixed in another patch? Don't see it happening as of r.19215.

[duck_]

Replying to azaozz:

Was this fixed in another patch? Don't see it happening as of r.19215.

I can still reproduce. Make sure that the categories meta box is in the right column, so it's output in #side-sortables, before switching to the one column layout. If it's already part of the main column it will not be targeted by the #side-sortables rule to change display to inline.

postbox.dev.js does

$('#normal-sortables').before( $('#side-sortables') );

in 3.2 it would append the children of #side-sortables with class .postbox.

[azaozz]

In [19219]:

Fix inline/block switching for the Categories postbox tabs, props linuxologos, fixes #19129

[azaozz]

Replying to duck_:

Yes, changed that to move the containers instead of individual postboxes. Has the advantage of keeping the postboxes in place when switching back.

[WraithKenny]

semi-related #17959