WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#19021 closed defect (bug) (fixed)

Broken pointers if attached to elements visible after scrolling page

Reported by: kkarpieszuk Owned by: koopersmith
Milestone: 3.4 Priority: normal
Severity: minor Version: 3.3
Component: Administration Keywords: needs-patch 3.3.1
Focuses: Cc:

Description

If you attach pointer for example to #footer it looks bad.

Try this code:

add_action( 'admin_enqueue_scripts', 'my_admin_enqueue_scripts' );
function my_admin_enqueue_scripts() {
    // Using Pointers
    wp_enqueue_style( 'wp-pointer' );
    wp_enqueue_script( 'wp-pointer' );

    // Register our action
    add_action( 'admin_print_footer_scripts', 'my_admin_print_footer_scripts' );
}

function my_admin_print_footer_scripts() {
    // This will run during footer scripts, use jQuery to show the pointer here.
    $pointer_content = '<h3>Test</h3>';
    $pointer_content .= '<p>Test';
?>
<script type="text/javascript">
//<![CDATA[
jQuery(document).ready( function($) {
    $('#footer').pointer({
        content: '<?php echo $pointer_content; ?>',
        position: 'bottom',
    }).pointer('open');
});
//]]>
</script>
<?php
}

as you can see, arrow is over the infobox and even infobox is under footer. http://minus.com/mbde0EcLFG

I think it heppens only when footer is not visible after page load. When i tried this on some admin page, where scroll bar is not visible (page is shorter than window height) pointer was ok.

Attachments (2)

pointer-error.png (16.9 KB) - added by kkarpieszuk 6 years ago.
screenshot
19021.diff (430 bytes) - added by blepoxp 6 years ago.
Reposition on screen resize or scroll

Download all attachments as: .zip

Change History (14)

@kkarpieszuk
6 years ago

screenshot

#1 @kkarpieszuk
6 years ago

  • Summary changed from Broken pointers if attached to elements visible after scroll of page to Broken pointers if attached to elements visible after scrolling page

#2 @ryan
6 years ago

  • Milestone changed from Awaiting Review to 3.3

#3 @blepoxp
6 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

I'm not a JS pro and there is probably a better place to put this in wp-pointer.js but the attached patch works for me.

@blepoxp
6 years ago

Reposition on screen resize or scroll

#4 @ocean90
6 years ago

  • Component changed from Widgets to Administration
  • Owner set to koopersmith
  • Status changed from new to reviewing

#5 @jane
6 years ago

Since we are not doing any below-fold pointers in this release, I don't think this should be a blocker. @koopersmith: In or out?

#6 @ocean90
6 years ago

A blocker not, but to re-position the pointer if the screen will be resized makes sense.

#7 follow-up: @koopersmith
6 years ago

  • Keywords needs-patch added; has-patch dev-feedback removed
  • Severity changed from normal to minor

Misplaced arrows should no longer be an issue (the positioning code was simplified when we added the new pointer styles).

We should reposition the pointers when the screen is resized, but should not do so every time the resize event is fired. An appropriate balance between accuracy and speed would be to hide the pointer as the window begins to resize, and show it again (thereby repositioning it) once the resize has completed (due to the resize event not being triggered for a set amount of time).

#8 in reply to: ↑ 7 @westi
6 years ago

Replying to koopersmith:

Misplaced arrows should no longer be an issue (the positioning code was simplified when we added the new pointer styles).

We should reposition the pointers when the screen is resized, but should not do so every time the resize event is fired. An appropriate balance between accuracy and speed would be to hide the pointer as the window begins to resize, and show it again (thereby repositioning it) once the resize has completed (due to the resize event not being triggered for a set amount of time).

Agreed.

I think this can wait for 3.3.1 ?

#9 @jane
6 years ago

@westi: Yes. Assuming 80%+ with a regular screen that's not being resized on the single instance they see the pointers before dismissing them, we shouldn't be bothering with this. They are they and they work as intended (show up, go away). Can refine in future versions.

#10 @jane
6 years ago

  • Keywords 3.3.1 added
  • Milestone changed from 3.3 to Future Release

#11 @koopersmith
6 years ago

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

In [19713]:

Improve pointer collision handling. fixes #19021.

#12 @SergeyBiryukov
6 years ago

  • Milestone changed from Future Release to 3.4
Note: See TracTickets for help on using tickets.