From cc9f7445f8349d2cbb03e7de46517fa61f4cd4ad Mon Sep 17 00:00:00 2001
From: Daniel Liu <liudaniel@qq.com>
Date: Mon, 30 Dec 2024 14:39:32 +0800
Subject: [PATCH] accounts: add function UnmarshalJSON to parse URL (#16154)

---
 accounts/url.go              | 16 ++++++++++++++++
 accounts/usbwallet/hub.go    |  2 +-
 accounts/usbwallet/wallet.go |  2 +-
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/accounts/url.go b/accounts/url.go
index d5c9c645c7256..c61d651116dbf 100644
--- a/accounts/url.go
+++ b/accounts/url.go
@@ -74,6 +74,22 @@ func (u URL) MarshalJSON() ([]byte, error) {
 	return json.Marshal(u.String())
 }
 
+// UnmarshalJSON parses url.
+func (u *URL) UnmarshalJSON(input []byte) error {
+	var textUrl string
+	err := json.Unmarshal(input, &textUrl)
+	if err != nil {
+		return err
+	}
+	url, err := parseURL(textUrl)
+	if err != nil {
+		return err
+	}
+	u.Scheme = url.Scheme
+	u.Path = url.Path
+	return nil
+}
+
 // Cmp compares x and y and returns:
 //
 //	-1 if x <  y
diff --git a/accounts/usbwallet/hub.go b/accounts/usbwallet/hub.go
index 4594c0a6c2fb5..2ec78d859d412 100644
--- a/accounts/usbwallet/hub.go
+++ b/accounts/usbwallet/hub.go
@@ -127,7 +127,7 @@ func (hub *Hub) refreshWallets() {
 		// breaking the Ledger protocol if that is waiting for user confirmation. This
 		// is a bug acknowledged at Ledger, but it won't be fixed on old devices so we
 		// need to prevent concurrent comms ourselves. The more elegant solution would
-		// be to ditch enumeration in favor of hutplug events, but that don't work yet
+		// be to ditch enumeration in favor of hotplug events, but that don't work yet
 		// on Windows so if we need to hack it anyway, this is more elegant for now.
 		hub.commsLock.Lock()
 		if hub.commsPend > 0 { // A confirmation is pending, don't refresh
diff --git a/accounts/usbwallet/wallet.go b/accounts/usbwallet/wallet.go
index 020a193d7599f..6778c2e01583a 100644
--- a/accounts/usbwallet/wallet.go
+++ b/accounts/usbwallet/wallet.go
@@ -99,7 +99,7 @@ type wallet struct {
 	//
 	// As such, a hardware wallet needs two locks to function correctly. A state
 	// lock can be used to protect the wallet's software-side internal state, which
-	// must not be held exlusively during hardware communication. A communication
+	// must not be held exclusively during hardware communication. A communication
 	// lock can be used to achieve exclusive access to the device itself, this one
 	// however should allow "skipping" waiting for operations that might want to
 	// use the device, but can live without too (e.g. account self-derivation).