Update @testing-library/user-event 14.5.2 → 14.6.0 (minor) #336
Conversation
![depfu[bot]](https://avatars.githubusercontent.com/in/715?s=60&v=4){kind=small}
|
The files' contents are under analysis for test generation. |
|
By default, I don't review pull requests opened by bots. If you would like me to review this pull request anyway, you can request a review via the |
|
Race Condition
DescriptionA Race Condition (also known as Time of Check to Time of Use) is a type of attack that exploits the order that an application carries out a task. Most commonly, the order in which a multi-threaded application performs a task. This allows an attacker to easily manipulate a shared resource to their gain. Race Conditions are nearly always caused by poor atomic programming practices. A programmer has attempted to use threads, for example, to handle multiple inbound connections but has allowed them all to access one resource with no restrictions. However, not all race conditions cause harm; therefore, priority setting in finding and fixing problematic race conditions is crucial when correcting them. While Race Conditions can appear in any programming language, some are much more resistant than others. An older programming language such as C, which gives full thread control and memory allocation to the programmer, is inherently more at risk due to minor mistakes having major complications. However, languages such as Go Lang come with built-in tools such as race detector, which natively support finding and fixing race conditions. These are much more resistant. Race Conditions can be hard to find. However, many companies offer continuous bug bounties for them, as many are found once out in production where an attack could cause significant damage. Static analysis can be used internally to identify possible race conditions before pushing to production. While not always prominent, race conditions have been around since the first multi-threaded applications, and as computer CPUs get more and more multi-threaded and, therefore, more of these applications, race conditions will not be going anywhere. Read moreImpactRace conditions can wreak internal havoc without even needing a malicious actor present. One of the worst bugs to directly affect human life was the Therac-25 radiotherapy machines. The company produced the software internally without much in the way of checks. After at least three people had died and many more were injured, it was discovered that a race condition was leading the machines to deliver over 100x the correct dose. Other examples without a malicious actor can be as simple as auto deployment and CI pipelines where a simple race condition there can incorrectly configure and deploy server tools which can interrupt the availability of the pipeline. Malicious users can use Race Conditions for personal gain, a bug on DropBox allowed users to redeem one 5GB voucher multiple times, resulting in a much larger amount given away. While not disastrous for DropBox, if this was financial or gift card related, such as this Reverb attack, it could cause much larger damage affecting the integrity of the storing database. ScenariosThe simplest race condition is where a call is made to a method, and then another method edits a variable halfway through. For example, a method to subtract 5 from a number such as x: def minus_five(x):
if x > 5: # Some arbitrary check
y = x - 5If between The use of locks here could fix this issue by: # Locking here
def minus_five(x):
if x > 5: # Some arbitrary check
y = x - 5
# Unlocking here once completePreventionPrevention of Race Conditions is entirely down to developers. Correct use of atomic programming and locks when required can completely mitigate the possibility of this type of attack. Shared synchronous variables are another way to check to see if the method is already running using a global variable that, if set, calls a wait until unset by the initial method. TestingMost testing of race conditions comes down to built-in tools or community-built plugins to analyze the code and attempt to find them. As mentioned above, static analysis is also valuable for finding possible race conditions.
|
Reviewer's Guide by SourceryThis PR updates the @testing-library/user-event package from version 14.5.2 to 14.6.0. This is a minor update that includes bug fixes and a new feature to dispatch FocusEvent in hidden documents. Notably, fixes were applied to clipboard handling, pointer event coordinates, and pointer position checks. Additionally, the update addresses an issue with awaiting DataTransferItem.getAsString callbacks. Sequence diagram for updated clipboard handling in @testing-library/user-eventsequenceDiagram
participant Test as Test Code
participant UE as user-event
participant DT as DataTransfer
Test->>UE: Trigger clipboard operation
UE->>DT: getAsString()
Note over UE,DT: Now properly awaits callback
DT-->>UE: Callback with string data
UE-->>Test: Operation complete
Sequence diagram for FocusEvent dispatch in hidden documentssequenceDiagram
participant Test as Test Code
participant UE as user-event
participant Doc as Hidden Document
Test->>UE: Trigger focus event
Note over UE: New feature
UE->>Doc: Dispatch FocusEvent
Doc-->>UE: Event handled
UE-->>Test: Operation complete
Class diagram for updated pointer coordinate handlingclassDiagram
class PointerCoords {
+number x
+number y
+isDifferentPointerPosition()
}
class MouseEvent {
+number clientX
+number clientY
+number pageX
+number pageY
}
note for PointerCoords "Now checks all coordinate fields"
note for MouseEvent "Now correctly assigns pointer coordinates"
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
github-actions
bot
added
the
size/S
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
gstraccini
bot
added
the
☑️ auto-merge
![gstraccini[bot]](https://avatars.githubusercontent.com/in/480132?s=60&v=4){kind=small}
|
@depfu merge |
|
Infisical secrets check: ✅ No secrets leaked! 💻 Scan logs9:42PM INF scanning for exposed secrets...
9:42PM INF 451 commits scanned.
9:42PM INF scan completed in 1.12s
9:42PM INF no leaks found
|
guibranco
deleted the
depfu/update/npm/@testing-library/user-event-14.6.0
branch
|
Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.
What changed?
✳️ @testing-library/user-event (14.5.2 → 14.6.0) · Repo · Changelog
Release Notes
14.6.0
Does any of this look wrong? Please let us know.
Commits
See the full diff on Github. The new version differs by 26 commits:
fix(pointer): check all fields of `PointerCoords` in `isDifferentPointerPosition()` (#1229)fix(pointer): check `PointerCoords.x` in `isDifferentPointerPosition` (#1216)fix(event): assign pointer coords to MouseEvent (#1039)fix(clipboard): await `DataTransferItem.getAsString()` callback (#1251)feat: dispatch `FocusEvent` in hidden documents (#1252)docs: add remcovaes as a contributor for bug (#1250)test: reset DTL `asyncWrapper` before asserting `setTimeout` callschore: add TODO to update `updateSelectionOnFocus`chore: add TODO to simulate `FocusEvent` in browserstest: convert flaky assertion on `<input type="file"/>` to TODOchore: upgrade testenv `react18`chore: print content of `console.error` callstest: get text nodes in wrapper per relative pathtest: `HTMLInputElement.focus()` in contenteditable changes selection in browsertest: range on focused contenteditable is defined in browsertest: exclude `select` events from screenshotstest: work around race condition with event handlertest: `Selection.setBaseAndExtent()` resets input selection in browserchore: add TODO to await `DataTransferItem.getAsString` callbacktest: expect `DataTransfer.types` to follow specstest: do not expect to report origin of `pointer-events: none` in browsertest: `window.getComputedStyle()` returns resolved style in browserrefactor: avoid declaring optional property per nullish coalescing assignmentchore: upgrade TestingLib packageschore: update testenv `node`chore: update toolbox test scriptDepfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with
@depfu rebase.All Depfu comment commands
Summary by Sourcery
Update @testing-library/user-event to v14.6.0.
New Features:
Bug Fixes:
Description by Korbit AI
What change is being made?
Update
@testing-library/user-eventfrom version 14.5.2 to 14.6.0 in thepackage.json.Why are these changes being made?
These changes are being made to incorporate the latest improvements and bug fixes available in the new minor version of
@testing-library/user-event, ensuring our application stays up-to-date with testing utilities. No breaking changes are expected, offering a smooth upgrade path.