Skip to content

Add optional prop to not dismiss Callout on focus loss#5106

Closed
jetao-msft wants to merge 1 commit intomicrosoft:5.0from
jetao-msft:no-dismiss-callout-5.0
Closed

Add optional prop to not dismiss Callout on focus loss#5106
jetao-msft wants to merge 1 commit intomicrosoft:5.0from
jetao-msft:no-dismiss-callout-5.0

Conversation

@jetao-msft
Copy link
Copy Markdown
Contributor

@jetao-msft jetao-msft commented Jun 5, 2018

Pull request checklist

  • Addresses an existing issue: Fixes #0000
  • Include a change request file using $ npm run change
  • Microsoft Alias (if you have one): jetao

Description of changes

This change adds an optional prop on Callout which, if set to true, prevents the Callout from dismissing itself when it loses focus. This is potentially useful in TeachingBubble cases where the Callout is unprompted and we may want the Callout to stick around until the user explicitly acknowledges it.

This is a backfix to 5.0 from #5092

Focus areas to test

(optional)

Microsoft Reviewers: Open in CodeFlow

* Add optional prop to not dismiss Callout on focus loss

* Change file

* Update no-dismiss-callout_2018-06-04-21-44.json
@jetao-msft jetao-msft requested a review from joschect as a code owner June 5, 2018 18:43
@jetao-msft
Copy link
Copy Markdown
Contributor Author

@dzearing This is a cherry pick from #5092 to 5.0. OWA has a scenario currently blocked on this change, but OWA has yet to upgrade to 6.0 (and it seems like we won't be upgrading for at least a little while).


if (
(!this._target && clickedOutsideCallout) ||
!preventDismissOnLostFocus &&
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This definitely shouldn't be here. Instead don't add the focus listener.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I can fix that. I was following the pattern of preventDismissOnScroll. Should I give it the same treatment?

Also this is a backfix from #5092 , I can make a follow-up PR on master to do the same thing.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, looking into how the listeners are registered, is it correct to not register them based on preventDismissOnLostFocus? If _addListeners has already been called, according to the semantics of _hasListeners, it will not be called again. We could enter a situation where you create the Callout with preventDismissOnLostFocus={true}, later update it to false, but the handlers will not be registered.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm. Yeah that's true. For now you're probably right. In the long term it should be streamlined in some way, or perhaps each type of dismiss should have it's own handler. So there would be onFocusDismiss and onScrollDismiss so the user could choose to pass or not pass those dismiss events through. But that should probably be for 7.0

For now keep things the way they are.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joschect do you approve this PR then? or are there changes needed?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OWA has actually upgraded to Fabric 6 in the meantime, so unless we feel this API would be useful for any other Fabric 5 users, I can abandon this PR.

@jetao-msft jetao-msft closed this Jun 20, 2018
@microsoft microsoft locked as resolved and limited conversation to collaborators Aug 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants