Make WordPress Core

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#19357 closed defect (bug) (fixed)

Pointers misplaced when object is hidden

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

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 15 years ago.

Download all attachments as: .zip

Change History (16)

#1 follow-up: @scribu
15 years ago

  • Version → 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.

#2 @scribu
15 years ago

  • Severity normal → minor

#3 @markoheijnen
15 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.

#4 @jane
15 years ago

I vote with @scribu.

#5 in reply to: ↑ 1 @CoenJacobs
15 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.

#6 follow-up: @scribu
15 years ago

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

#7 in reply to: ↑ 6 @CoenJacobs
15 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.

#8 @nacin
15 years ago

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

#9 @nacin
15 years ago

  • Keywords needs-patch added
  • Milestone Awaiting Review → 3.3
  • Priority normal → low

#10 @SergeyBiryukov
15 years ago

  • Keywords has-patch added; needs-patch removed

#11 @nacin
15 years ago

In [19467]:

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

#12 @nacin
15 years ago

  • Keywords close added
  • Owner set to koopersmith
  • Status new → reviewing

#13 @koopersmith
15 years ago

  • Resolution → fixed
  • Status reviewing → closed

In [19482]:

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

#14 @koopersmith
15 years ago

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

#15 @koopersmith
15 years ago

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