profile
viewpoint
Andrew Campbell AndrewOCC Sydney, Australia Graduate Software Engineer at Atlassian, working on the Atlassian Design System Team ❤️

AndrewOCC/SDD-Major-Project-Game 1

High-school Android game with Google Play Games integration. First exposure to object-oriented code!

AndrewOCC/Swiper-Hackathon 1

Basic Android application based on sample code from the Freelancer Hackathon

AndrewOCC/COMP2129-PageRank 0

C-based, basic implementation of PageRank with threading, as the final assessment for a university Operating Systems course

AndrewOCC/Databases-RM-conversion 0

DML/DDL for Databases group assignment- requirement was to convert an ER model into a relational database

AndrewOCC/info1905-assignment1 0

INFO1905 Data Structures Assignment 1 (tree traversal and arithmetic trees)

AndrewOCC/info1905-assignment2 0

INFO1905 Data Structures Assignment 2 (password manager)

AndrewOCC/NoMoss-Makers-resilience 0

Personal reflection note-taking app made in React Native

AndrewOCC/popper-core 0

🍿Positioning tooltips and popovers is difficult. Popper is here to help!

AndrewOCC/react-popper 0

🍿⚛Official React library to use Popper, the positioning library

AndrewOCC/README 0

Summary of current and past projects outside of GitHub

startedGaboze-Pocaio/Round-2

started time in 12 hours

issue commentpopperjs/popper-core

Strategy "fixed" generates incorrect popper position in Safari

I took some time to investigate this issue today, and it looks like like the issue is caused at least in part by a Webkit bug with calculating getBoundingClientRect() when using pinch-to-zoom. Popper.js wraps this function and uses it in a bunch of places to calculate positioning. I assume the same bug causes the inconsistencies with offsetParent that Dan mentioned above.

The bug is tracked in the Webkit issue tracker here, including a simpler popper example as a demonstration: https://bugs.webkit.org/show_bug.cgi?id=207089

I'll look into whether there's an alternate way we can calculate the reference's bounding box and position, and will update in a few hours

s-belous

comment created time in a month

fork AndrewOCC/popper-core

🍿Positioning tooltips and popovers is difficult. Popper is here to help!

https://popper.js.org

fork in a month

fork AndrewOCC/react-popper

🍿⚛Official React library to use Popper, the positioning library

https://popper.js.org/react-popper/

fork in a month

issue commentpopperjs/react-popper

Act warning in tests

I'm also encountering this same issue running tests with the Render Props version of popper – we're on React 16.8.x so we don't have access to async act() to mitigate the issue.

I've included a basic example test below that raises the error:

import React, { useState } from 'react';
import { render } from '@testing-library/react';
import { Manager, Popper, Reference } from 'react-popper';
function BasicPopper () {
  return(
    <Manager>
      <Reference>{({ ref }) => <div ref={ref}>Reference element</div>}</Reference>
        <Popper>
          {({ ref, style }) => (
            <div ref={ref} style={style}>
              foo bar
            </div>
          )}
        </Popper>
    </Manager>
  )
};
test('act warning', () => {
  render(<BasicPopper />);
});```
nstepien

comment created time in a month

issue openedpopperjs/popper-core

Popper positioning (strategy = 'fixed') broken in ie11

<!--

CodeSandbox demo

ie11 doesn't support CodeSandbox, but here's a JSBin that shows the same issue: https://jsbin.com/nakizamosi/1/edit

Steps to reproduce the problem

  1. Create a popper example using either @popperjs/core or react-popper that sets strategy = 'fixed'
  2. View in IE11
  3. Popper will not position correctly

What is the expected behavior?

The popper should position in a similar fashion to other browsers

What went wrong?

When using strategy: 'fixed' the popper appears in the wrong spot on the page – as if it is offset by some large number of pixels. Flipping and hiding appears to work, but not positioning. strategy: 'absolute' works fine

Any other comments?

As this is a major regression for ie11, if the issue is a 'won't fix' it would be useful to add a warning to the upgrade guide that ie11 support for position: fixed has been dropped or has rendering issues.

created time in a month

issue closedpopperjs/popper-core

preventOverflow should allow root boundaries to be set to `window`

Feature description

One use case for the preventOverflow modifier would be to allow the popper to be constrained to the boundaries of the window. When the user is zoomed in at high magnifications (200/400%) or has reduced their viewport size, the window may extend past the edge of the viewport; the requested behaviour would allow the user to move the viewport around the window without the popper 'following' them.

Currently in popper v2, rootBoundary can only be set to viewport or document. rootBoundary: 'document' isn't helpful for this case, as at high zoom levels the document boundaries are a viewport-sized bounding box in the top left of the page, so a reference elements sitting outside of the document boundary are positioned as if the reference is off-screen. With rootBoundary set to viewport the popper will stick to the edges of the viewport as you scroll around; a big enough popup may obscure large parts of the screen until the reference is completely off-screen.

An example for experimenting with this behaviour in popper v2 is in this codesandbox: https://codesandbox.io/s/small-hill-lpc3i?file=/src/index.js Zoom in so that the reference element is partially out of the viewport on load, and move around. There doesn't appear to be a configuration of preventOverflow that allows the popper to sit directly below the reference and not shift to sit the boundaries of the viewport or document, without disabling preventOverflow entirely and losing overflow prevention on the edges of the window.

This behaviour was supported in popper v1 via the boundariesElement option: https://codesandbox.io/s/holy-wood-jmw9u?file=/src/index.js

Why should this feature be part of the Popper's core?

Allowing the popper to behave independently of the viewport at high zoom settings or viewport positions is useful as it can allow the user to scroll around a page without the popper 'following them', while also keeping the popper from overflowing the window and being partially obscured.

This makes sense as core behaviour as it's restoring functionality to a core modifier, preventOverflow, and that modifier has a rootBoundary option where this option could logically be added (similar to boundariesObject in popper v1)

closed time in 2 months

AndrewOCC

issue commentpopperjs/popper-core

preventOverflow should allow root boundaries to be set to `window`

Thanks for the help, I'll mark this as resolved then

AndrewOCC

comment created time in 2 months

issue commentpopperjs/popper-core

preventOverflow should allow root boundaries to be set to `window`

Oh that's great news, thanks for the quick response 😄 Follow-up question (I can raise a ticket around it if it's not supported); is there a way to allow hide to only occur when the popper leaves the window?

AndrewOCC

comment created time in 2 months

issue openedpopperjs/popper-core

preventOverflow should allow root boundaries to be set to `window`

Feature description

One use case for the preventOverflow modifier would be to allow the popper to be constrained to the boundaries of the window. When the user is zoomed in at high magnifications (200/400%) or has reduced their viewport size, the window may extend past the edge of the viewport; the requested behaviour would allow the user to move the viewport around the window without the popper 'following' them.

Currently in popper v2, rootBoundary can only be set to viewport or document. rootBoundary: 'document' isn't helpful for this case, as at high zoom levels the document boundaries are a viewport-sized bounding box in the top left of the page, so a reference elements sitting outside of the document boundary are positioned as if the reference is off-screen. With rootBoundary set to viewport the popper will stick to the edges of the viewport as you scroll around; a big enough popup may obscure large parts of the screen until the reference is completely off-screen.

An example for experimenting with this behaviour in popper v2 is in this codesandbox: https://codesandbox.io/s/small-hill-lpc3i?file=/src/index.js Zoom in so that the reference element is partially out of the viewport on load, and move around. There doesn't appear to be a configuration of preventOverflow that allows the popper to sit directly below the reference and not shift to sit the boundaries of the viewport or document, without disabling preventOverflow entirely and losing overflow prevention on the edges of the window.

This behaviour was supported in popper v1 via the boundariesElement option: https://codesandbox.io/s/holy-wood-jmw9u?file=/src/index.js

Why should this feature be part of the Popper's core?

Allowing the popper to behave independently of the viewport at high zoom settings or viewport positions is useful as it can allow the user to scroll around a page without the popper 'following them', while also keeping the popper from overflowing the window and being partially obscured.

This makes sense as core behaviour as it's restoring functionality to a core modifier, preventOverflow, and that modifier has a rootBoundary option where this option could logically be added (similar to boundariesObject in popper v1)

created time in 2 months

startedduke7553/files-uwp

started time in 3 months

more