#10646 closed task (blessed) (fixed)
Admin Menus Shouldn't Jump Around on Pageload
Reported by: | filosofo | Owned by: | |
---|---|---|---|
Milestone: | 3.2 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | 3.2-early has-patch needs-testing |
Focuses: | Cc: |
Description (last modified by )
Problem: When I open an admin page, I see the menu item I want and go to click it, and just at that moment the admin menu suddenly expands so that I click the wrong item.
Solution: Instead of expanding the menus by retrieving their saved state and adding open classes with JavaScript, we should retrieve the saved state from usermeta (it's already being saved there) and print the menus with appropriate classes, accordingly, so that there is no jump.
Attachments (6)
Change History (32)
#2
in reply to:
↑ 1
@
15 years ago
Replying to strider72:
If we make the change you suggest, I believe there will be no way to close a menu if someone accesses Admin without JavaScript.
Well, currently if you access the admin without JavaScript there's no way to open a menu, except for the current children and ones preset as open, so there doesn't seem to be too much concern about allowing the non-JS folks flexibility with saved open/close states.
However, if that's something people want, we could just make the open/close arrows into links that accomplish state change for non-JS users. That might be a good idea anyways, since the current, non-JS menu has arrows that do nothing.
#6
@
15 years ago
- Keywords early added
- Milestone changed from Future Release to 3.1
Should be looked at with #11957.
#7
@
14 years ago
I'm constantly clicking wrong menu items because of this problem, the suggestion is sound for me, i'd much prefer classes to be added to the elements on page load, so we avoid all this jumping around.
#8
@
14 years ago
- Keywords 3.2-early added; early removed
- Milestone changed from Awaiting Triage to Future Release
Marking for 3.2-early. I want to tackle this.
#10
@
14 years ago
Thanks for doing this!
You can probably kill wp_get_current_user() and the extra argument to get_user_option(), which defaults to the current user.
Actually, avoid get_user_option() all together, and leverage get_user_setting() and/or get_all_user_settings().
#13
@
14 years ago
10646.diff takes a different approach, to support no-JS situations. Also, the increment occurs in a different spot, as only top-level menus that have a submenu are actually counted. (Otherwise, the comments menu throws off the lower menus.)
#14
@
14 years ago
Second patch changes the logic on wp-admin/menu-header.php:61 to ensure only menus with submenus are checked against the user settings. Otherwise for example the Comments menu will get wp-menu-open-if-js if Pages is open, despite it not doing anything.
#15
@
14 years ago
- Milestone changed from Future Release to 3.2
- Type changed from defect (bug) to task (blessed)
#16
@
14 years ago
10646-3.patch is almost identical to 10646.2.diff except it uses only CSS to initially open/close the menus so it doesn't require any JS to run on DOM ready.
#17
follow-up:
↓ 22
@
14 years ago
With the last patch (10646-3.patch) applied and under no-js mode, the Posts menu is always displayed (expanded). For me, it's bad behavior.
Edit
The Problem seem to be not linked to the patch since it's same behavior in current version.
Edit:
Ok; that seem to be another bug, but I don't know if I must create separate ticket for it... In no-js mode, the Posts menu is always expanded because the menu has always the class open-if-no-js added to it. I doesn't known if it's the expected behavior or not. If yes, why ?
For me, under no-js mode, the open-if-no-js must be only added on the current menu (linked to the current loaded admin page).
To finish, I thinks that under no-js mode, all arrows that allow to expand the submenus in js mode must be hidden.
I'll provide a modified version of the current patch , which will include all these considerations.
Note: Sorry for the empty comments bellow. I've found the edit option too late.
#20
@
14 years ago
10646-4.patch is almost identical to 10646-3.patch. It include the following fixes:
- Under no-js mode, only the menu linked to the current loaded page is expanded ;
- Under no-js mode, all arrows are hidden.
The patch also includes the fix linked to the #17058 issue.
#22
in reply to:
↑ 17
;
follow-up:
↓ 23
@
14 years ago
Replying to nuxwin:
With the last patch (10646-3.patch) applied and under no-js mode, the Posts menu is always displayed (expanded). For me, it's bad behavior.
This is an UX decision. Since the Posts submenu is the most used one, it's always open when no-js.
To finish, I thinks that under no-js mode, all arrows that allow to expand the submenus in js mode must be hidden.
Agreed.
#23
in reply to:
↑ 22
@
14 years ago
Replying to azaozz:
Replying to nuxwin:
With the last patch (10646-3.patch) applied and under no-js mode, the Posts menu is always displayed (expanded). For me, it's bad behavior.
This is an UX decision. Since the Posts submenu is the most used one, it's always open when no-js.
To finish, I thinks that under no-js mode, all arrows that allow to expand the submenus in js mode must be hidden.
Agreed.
Ok so, I'll update the patch according this UX decision. For me, it's a bad decision but it's only my personal opinion.
If we make the change you suggest, I believe there will be no way to close a menu if someone accesses Admin without JavaScript.