Renaming a tag in the Library doesn't show its new name until the Library gets reopened

VERIFIED FIXED in Firefox 3.7a1

Status

()

Firefox
Bookmarks & History
P2
normal
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: whimboo, Assigned: mano)

Tracking

({regression, verified1.9.2})

Trunk
Firefox 3.7a1
regression, verified1.9.2
Points:
---
Bug Flags:
blocking-firefox3.6 +
in-testsuite +

Firefox Tracking Flags

(status1.9.2 beta2-fixed)

Details

(Whiteboard: [3.6b1])

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1) Gecko/20091014 Firefox/3.6b1

Renaming a tag inside the Library doesn't update its name until the Library is reopened.

Steps:
1. Open the Library
2. Select any bookmark and add the tag "test"
3. Expand the tags container and select the tag "test"
4. Change its name
5. Click somewhere outside of the textbox 

After step 5 the tag still shows its old name.
Flags: blocking-firefox3.6?
(Reporter)

Comment 1

9 years ago
Oh, and that happens on all platforms for me.
OS: Mac OS X → All
Whiteboard: [3.6b1]
I am not able to reproduce this using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1) Gecko/20091019 Firefox/3.6b1 - Henrik it looks as if you are using the first beta build - can you try the second build?
(Reporter)

Comment 3

9 years ago
It doesn't matter. The same happens in todays nightly too.
i suppose could be a regression from bug 498130.

We should check the builds before and after it landed.
Marco, you're right.
this regressed within
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e109f9a3b6ee&tochange=149c3820e8a8
(i only have hourly builds before/after the 1st landing of that patch, but that shouldn't matter).
Blocks: 498130
Keywords: regressionwindow-wanted
(Reporter)

Comment 6

9 years ago
(In reply to comment #5)
> Marco, you're right.
> this regressed within
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e109f9a3b6ee&tochange=149c3820e8a8

The patch has been written by Asaf. Lets cc him. Thanks for checking the range.
Mano, can you fix?
Flags: blocking-firefox3.6? → blocking-firefox3.6+
Priority: -- → P2
Assignee: nobody → mano
Status: NEW → ASSIGNED

Updated

9 years ago
Attachment #408699 - Flags: review?(mak77) → review+
Comment on attachment 408699 [details] [diff] [review]
patch

>diff --git a/toolkit/components/places/tests/unit/test_419731.js b/toolkit/components/places/tests/unit/test_419731.js

>-  root.containerOpen = false;
>+  theTag.containerOpen = false;

nit: close root

Thanks!

Updated

9 years ago
Flags: in-testsuite?
mc: 448f4866de46
192: b5ce20227bab
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
status1.9.2: --- → beta1-fixed
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
b1 has already a separate branch so this is final-fixed
thanks.
status1.9.2: beta1-fixed → final-fixed
(Reporter)

Comment 12

9 years ago
Verified fixed on trunk and 1.9.2 with builds on OS X:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091101 Minefield/3.7a1pre ID:20091101031119

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b2pre) Gecko/20091030 Namoroka/3.6b2pre ID:20091030043032
Status: RESOLVED → VERIFIED
Keywords: verified1.9.2
Target Milestone: --- → Firefox 3.7a1
You need to log in before you can comment on or make changes to this bug.