New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Components: Set type=button for TabPanel button elements. #11944

Merged
merged 4 commits into from Jan 30, 2019

Conversation

Projects
None yet
5 participants
@TimothyBJacobs
Copy link
Contributor

TimothyBJacobs commented Nov 15, 2018

Fixes #11767.

Description

The default button type is "submit" which submits the enclosing form.
Setting the type property to "button" prevents this behavior.

I don't think it ever makes sense that you'd want a button in a tab panel to submit the form,
so I just made the type="button" behavior for everything. Otherwise, a prop could be added to adjust the button type.

How has this been tested?

I tried to write a unit test for this, but apparently an onSubmit handler on a form will never be called from a button being clicked because it's not actually simulating the DOM?

Types of changes

Bug fix.

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
Components: Set type=button for TabPanel button elements.
The default button type is "submit" which submits the enclosing form.
Setting the type property to "button" prevents this behavior.
@ajitbohra
Copy link
Member

ajitbohra left a comment

LGTM 👍

@aduth

This comment has been minimized.

Copy link
Member

aduth commented Dec 3, 2018

Had you considered changing this to use the Button component, which defaults to type="button"?

@TimothyBJacobs

This comment has been minimized.

Copy link
Contributor Author

TimothyBJacobs commented Dec 3, 2018

I hadn’t. That would make sense though. I’ll see what that looks like.

@TimothyBJacobs

This comment has been minimized.

Copy link
Contributor Author

TimothyBJacobs commented Dec 4, 2018

Switching out for the <Button> component looks good.

@aduth

This comment has been minimized.

Copy link
Member

aduth commented Dec 11, 2018

There's a stylistic difference:

Before After
screen shot 2018-12-11 at 2 50 01 pm screen shot 2018-12-11 at 2 51 00 pm

I'm not really sure what this component is meant to look like. It seems a bit useless in its current form.

@TimothyBJacobs

This comment has been minimized.

Copy link
Contributor Author

TimothyBJacobs commented Dec 11, 2018

Ah. I guess because I already had provided the styles for my usage of it.

Yeah, style wise the existing component is incredibly barebones.

@gziolo gziolo added this to the 5.0 (Gutenberg) milestone Jan 25, 2019

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Jan 29, 2019

@jasmussen would mind giving it a sping to validate it doesn't introduce any regressions for tabs?

@gziolo gziolo requested review from jasmussen , kjellr , mapk and sarahmonster Jan 30, 2019

@jasmussen

This comment has been minimized.

Copy link
Contributor

jasmussen commented Jan 30, 2019

@gziolo Thanks for the ping. I took this for a spin and added this to the separator to test:

tabpanel

It doesn't seem like we're using this component anywhere in Gutenberg itself. It really seems like it should come with some basic styles, and I'm essentially echoing @aduth here. This is because the Button component unsets the appearance and border of the button, so it's really quite bare.

But maybe that shouldn't hold up this PR if it fixes an issue? Not sure, and not sure how I can review this from a design perspective as there doesn't seem to be a design.

To put it more simply, if the above was the design we intended for the TabPanel component, it would not be shippable. But this could be a separate task, to improve that, as mentioned.

@gziolo gziolo merged commit 5105c19 into WordPress:master Jan 30, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Jan 30, 2019

I merged this PR as is given that it doesn't have any impact on Gutenberg itself as I confirmed that this component is never used in the codebase. The change itself fixes the issue it references but let's work on the styles related improvements in a separate issue. I opened #13587 to track it. Let's discuss further steps there as it needs some design involvement.

daniloercoli added a commit that referenced this pull request Jan 30, 2019

Merge branch 'master' of https://github.com/WordPress/gutenberg into …
…rnmobile/372-use-RichText-on-Title-block

* 'master' of https://github.com/WordPress/gutenberg: (36 commits)
  Fixes plural messages POT generation. (#13577)
  Typo fix (#13595)
  REST API: Remove oEmbed proxy HTML filtering (#13575)
  Removed unnecessary className attribute. Fixes #11664 (#11831)
  Add changelog for RSS block (#13588)
  Components: Set type=button for TabPanel button elements. (#11944)
  Update util.js (#13582)
  Docs: Add accessbility specific page (#13169)
  Rnmobile/media methods refactor (#13554)
  chore(release): publish
  chore(release): publish
  Plugin: Deprecate gutenberg_get_script_polyfill (#13536)
  Block API: Parse entity only when valid character reference (#13512)
  RichText: List: fix indentation (#13563)
  Plugin: Deprecate window._wpLoadGutenbergEditor (#13547)
  Plugin: Avoid setting generic "Edit Post" title on load (#13552)
  Plugin: Populate demo content by default content filters (#13553)
  RichText: List: Fix getParentIndex (#13562)
  RichText: List: Fix outdent with children (#13559)
  Scripts: Remove npm run build from test-e2e default run (#13420)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment