WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#19357 closed defect (bug) (fixed)

Pointers misplaced when object is hidden

Reported by: markoheijnen Owned by: koopersmith
Milestone: 3.3 Priority: low
Severity: minor Version: 3.3
Component: UI Keywords: has-patch
Focuses: Cc:

Description

I got a small issue with the new pointers (media upload pointer). It was hiding behind the admin bar since I had the editor hidden trough CSS. Probably a case that is not likely to see for a lot of users

Attachments (1)

19357.patch (429 bytes) - added by SergeyBiryukov 3 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 follow-up: scribu3 years ago

  • Version set to 3.3

You can hide the editor by modifying the 'supports' parameter of the post type.

I suggest closing as 'worksforme', unless there's potential to make the pointer JS more robust.

comment:2 scribu3 years ago

  • Severity changed from normal to minor

comment:3 markoheijnen3 years ago

I do need it on the edit page but only when a tab is selected. This due some possible large meta_boxes.
The reason I post it as a bug is due the possibility that in other rare cases this can happen.

comment:4 jane3 years ago

I vote with @scribu.

comment:5 in reply to: ↑ 1 CoenJacobs3 years ago

Replying to scribu:

You can hide the editor by modifying the 'supports' parameter of the post type.

Not valid if you want to hide it temporarily. I can imagine some kind of 'wizard like' (been there, done that) way of creating pages, where you only want to show the editor after entering the title. The editor won't be visible at page load, so the pointer can't be placed at the correct position. Simple as pie: If the target object is not there, the pointer shouldn't be placed.

comment:6 follow-up: scribu3 years ago

Yes, except in this case, the DOM element is there, but it's hidden.

comment:7 in reply to: ↑ 6 CoenJacobs3 years ago

Replying to scribu:

Yes, except in this case, the DOM element is there, but it's hidden.

Correct, but it doesn't make sense to show a pointer at a hidden element. Look at it from an user perspective, seeing pointers where the element is hidden, doesn't make sense. I agree that it isn't easy to fix and not a lot of users will have to face it, but problem lies in the base of the way pointers work.

comment:8 nacin3 years ago

I agree with Coen. We should simply ensure that a pointer's target element is visible first.

comment:9 nacin3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 3.3
  • Priority changed from normal to low

SergeyBiryukov3 years ago

comment:10 SergeyBiryukov3 years ago

  • Keywords has-patch added; needs-patch removed

comment:11 nacin3 years ago

In [19467]:

Don't open a pointer when the target element is hidden. see #19357.

comment:12 nacin3 years ago

  • Keywords close added
  • Owner set to koopersmith
  • Status changed from new to reviewing

comment:13 koopersmith3 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In [19482]:

Don't open a pointer when the target element is hidden. fixes #19357.

comment:14 koopersmith3 years ago

Just tweaked the logic slightly and added a check to _open as well.

comment:15 koopersmith3 years ago

  • Keywords close removed
Note: See TracTickets for help on using tickets.