Closed Bug 492802 Opened 16 years ago Closed 16 years ago

library details pane is refreshed on focus even when contents haven't changed

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 3.6a1

People

(Reporter: dietrich, Assigned: dietrich)

Details

(Keywords: perf, Whiteboard: [TSnappiness])

Attachments

(1 file, 3 obsolete files)

Attached patch v1 (obsolete) — Splinter Review
should check concrete id
Attachment #377212 - Flags: review?(mak77)
Whiteboard: [TSnappiness]
Attached patch v1, cleaned (obsolete) — Splinter Review
Attachment #377212 - Attachment is obsolete: true
Attachment #377220 - Flags: review?(mak77)
Attachment #377212 - Flags: review?(mak77)
Comment on attachment 377220 [details] [diff] [review] v1, cleaned i think there are cases where we do edit the shortcut and not the concreteId... i'm thinking to shortcut to roots probably (could you please check?) Maybe check for both itemId and concreteItemId? What about history nodes, those have itemId = -1, but are still shown in the details deck, maybe we can check uris too?
Comment on attachment 377220 [details] [diff] [review] v1, cleaned clearing request while waiting for answers to comment 2, feel free to reask for review when you're ready.
Attachment #377220 - Flags: review?(mak77)
Attached patch v2 (obsolete) — Splinter Review
addressed comments
Attachment #377220 - Attachment is obsolete: true
Attachment #378115 - Flags: review?(mak77)
Comment on attachment 378115 [details] [diff] [review] v2 >diff --git a/browser/components/places/content/editBookmarkOverlay.js b/browser/components/places/content/editBookmarkOverlay.js >--- a/browser/components/places/content/editBookmarkOverlay.js >+++ b/browser/components/places/content/editBookmarkOverlay.js >@@ -56,16 +56,20 @@ var gEditItemOverlay = { > _initialized: false, > > // the first field which was edited after this panel was initialized for > // a certain item > _firstEditedField: "", > > get itemId() { > return this._itemId; >+ }, >+ >+ get uri() { >+ return this._uri; > }, > > get multiEdit() { > return this._multiEdit; > }, > > /** > * Determines the initial data for the item edited or added by this dialog >diff --git a/browser/components/places/content/places.js b/browser/components/places/content/places.js >--- a/browser/components/places/content/places.js >+++ b/browser/components/places/content/places.js >@@ -653,19 +653,26 @@ var PlacesOrganizer = { > var focusedElement = document.commandDispatcher.focusedElement; > if ((focusedElement instanceof HTMLInputElement || > focusedElement instanceof HTMLTextAreaElement) && > /^editBMPanel.*/.test(focusedElement.parentNode.parentNode.id)) > focusedElement.blur(); > > // don't update the panel if we are already editing this node unless we're > // in multi-edit mode >- if (aSelectedNode && gEditItemOverlay.itemId == aSelectedNode.itemId && >- detailsDeck.selectedIndex == 1 && !gEditItemOverlay.multiEdit) >- return; >+ if (aSelectedNode) { >+ var concreteId = PlacesUtils.getConcreteItemId(aSelectedNode); >+ var nodeIsSame = gEditItemOverlay.itemId == aSelectedNode.itemId || >+ gEditItemOverlay.itemId == concreteId || >+ (gEditItemOverlay.uri && >+ gEditItemOverlay.uri == aSelectedNode.uri); 2 different bookmarks could have the same uri but different titles or tags, this would catch them. The uri check should include aSelectedNode.itemId == -1 r=me with that fixed
Attachment #378115 - Flags: review?(mak77) → review+
Attachment #378115 - Attachment is obsolete: true
Whiteboard: [TSnappiness] → [TSnappiness][can land]
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [TSnappiness][can land] → [TSnappiness]
Target Milestone: --- → Firefox 3.6a1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: