Page MenuHomePhabricator

[web] [fix] remove border-radius in input type="submit"
ClosedPublic

Authored by benschac on Feb 24 2022, 12:51 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Jan 6, 11:42 PM
Unknown Object (File)
Mon, Jan 6, 11:42 PM
Unknown Object (File)
Mon, Jan 6, 11:42 PM
Unknown Object (File)
Mon, Jan 6, 11:41 PM
Unknown Object (File)
Mon, Jan 6, 11:35 PM
Unknown Object (File)
Fri, Dec 27, 8:18 AM
Unknown Object (File)
Fri, Dec 27, 8:17 AM
Unknown Object (File)
Fri, Dec 27, 8:17 AM

Details

Summary

I've got this error in my VSCode for a while. Not sure why -webkit prefix was used here, I'm assuming it's just really old css. Border radius is a widely supported css property. https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius#browser_compatibilit)

Update:

We no-longer use these css declarations in the code, so I'm removing them.

Test Plan

N/A

Diff Detail

Repository
rCOMM Comm
Branch
fix-border-radius
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

It was probably from some CSS unset I copied from way back. I'm guessing it's -webkit-specific because maybe Webkit was the only engine that applied border-radius by default to input[type='submit']

atul requested changes to this revision.Feb 25 2022, 9:06 AM

Not sure why -webkit prefix was used here

Can we check where it's used and then make sure things continue to look expected on Safari?

This revision now requires changes to proceed.Feb 25 2022, 9:06 AM

The only place <input type='submit' is used is ConfirmLeaveThreadModal and that component is never used in the codebase.

I'm going to delete this line entirely.

Confirming: After searching the code base the only place <input type="submit" is used is in <ConfirmLeaveThreadModal` which after grepping is not used in the code base.

benschac retitled this revision from [web] [fix] border-radius in submit doesn't need prefix to [web] [fix] remove border-radius in input type="submit".Mar 1 2022, 7:22 AM
This revision is now accepted and ready to land.Mar 3 2022, 12:29 PM
This revision now requires review to proceed.Mar 3 2022, 12:30 PM
This revision is now accepted and ready to land.Mar 3 2022, 10:30 PM
ashoat requested changes to this revision.Mar 3 2022, 10:31 PM

Just a question – in case we use an input[type='submit'] in the future (seems likely) – do we currently have a CSS reset in place that does the equivalent of these lines that are being removed?

This revision now requires changes to proceed.Mar 3 2022, 10:31 PM
In D3288#89804, @ashoat wrote:

Just a question – in case we use an input[type='submit'] in the future (seems likely) – do we currently have a CSS reset in place that does the equivalent of these lines that are being removed?

We don't have a CSS reset. I think having one would be a great idea.
https://linear.app/comm/issue/ENG-826/implement-css-reset

Confirming: After searching the code base the only place <input type="submit" is used is in <ConfirmLeaveThreadModal` which after grepping is not used in the code base.

I was about to accept based on the claim that we don't have any input[type='submit'], but then figured I should double-check.

Good thing I double-checked. I found input[type='submit'] in ConcurrentModificationModal, NewThreadModal, and ThreadSettingsModal (along with ConfirmLeaveThreadModal).

@benschac, I think this is the second time in the last couple weeks you've missed something significant while git greping. We need to be able to rely on the claims you make in diffs... right now, I find myself having to double-check everything. Please try and spend some time analyzing what went wrong here.

Good thing I double-checked. I found input[type='submit'] in ConcurrentModificationModal, NewThreadModal, and ThreadSettingsModal (along with ConfirmLeaveThreadModal).

@benschac, I think this is the second time in the last couple weeks you've missed something significant while git greping. We need to be able to rely on the claims you make in diffs... right now, I find myself having to double-check everything. Please try and spend some time analyzing what went wrong here.

I took a couple of minutes to try and figure out where my searching went wrong.

Image 2022-03-08 at 10.15.35 AM.jpg (1×2 px, 119 KB)

FWIR -- I probably grepped for the wrong thing along the lines of git grep "<input type="submit". Which wouldn't get me every instance of an input with the type submit. I should have grepped for something like: git grep "type=submit" I would have seen the same issue as you did.

Going forward I'm going to grep a bit more intentionally and think more about how to search on the codebase. Looking back on it, it makes sense that I would miss something like this because of how I searched on it.

Makes sense, glad to hear you figured out what went wrong and know how to improve.

To unblock this diff, can you make sure that it's not causing any regressions in any of the above listed modals?

In D3288#90945, @ashoat wrote:

Makes sense, glad to hear you figured out what went wrong and know how to improve.

To unblock this diff, can you make sure that it's not causing any regressions in any of the above listed modals?

Yep, I added (and linked) another diff as a parent to this diff updating all of the modal buttons to use the Button component and not an input field with a submit type.

Going to re-request review now that all of the input elements using type="submit" (in the modals you mentioned above) have been updated in the parent diff.

This revision is now accepted and ready to land.Mar 14 2022, 9:35 PM