1272816 - Bookmark description field shouldn't replaced by buffered description.

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, defect, P3)

Description

[limkokhole]

Attachment: 1463184829_2016-05-14_4LclYAqyGL.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

Steps to reproduce:

1. My platform is Fedora 21, firefox 46.0.1(latest stable release at this time of writing).

2. I have this file to enabled description field in firefox bookmark dialog when click the star icon:

[xiaobai@xiaobai chrome]$ cat userChrome.css 
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* only needed once */

#editBMPanel_locationRow { visibility:visible!important; }
#editBMPanel_descriptionRow { visibility:visible!important; }
#editBMPanel_keywordRow { visibility:visible!important; }

3. But if you visit a new URL, click a bookmark star to add  the new bookmark, insert description "hello" in the text box, then if i visits another website, then click the bookmark star icon, it will show the "hello" fill in by default. So far so good because i can reuse the description, right ?




Actual results:

4. But it cause a problem when i access previously bookmarked by click the star icon, because it will fill in by this latest "buffered" description (in current window session), even though difference description has been saved before, e.g. "world".


Expected results:

5. It shouldn't fill in by latest "buffered" description in the description text box, it should display the saved description. 

Impact:
I have no way to know the exiting bookmark has description or not (Unless i put some unique identity text) due to it always fill in by latest "buffered" description. And i can't edit the description because it will replace the exiting description(sometime not sync in the library manager, so it's weird, but if you open the library dialog -> point to the bookmark's description text box, then in the same time open  the bookmark star dialog, edit the description in this dialog, it will reflects immediately in library dialog).

So i suggest never fill in latest "buffered" description by default in bookmark star dialog, otherwise i believe bookmark dialog has no way to determine it's a new bookmarked dialog(click star twice consecutive to add, the 2nd click will distinguishable because it's considered bookmarked) or existing bookmarked dialog.

Sorry for my poor English, but the situation is quite complicated.

But the bug can be summarized, the latest edited/added description text always appear in the next description text box, and replaced the existing bookmarked description which is wrong.

Attached is the screenshot of bookmarked star description replaced by latest description text in current window session, which hiding the actual description text.

Comment 1

[limkokhole]

Typo correction (indistinguishable):

So i suggest never fill in latest "buffered" description by default in bookmark star dialog, otherwise i believe bookmark dialog has no way to determine it's a new bookmarked dialog(click star twice consecutive to add, the 2nd click will indistinguishable because it's considered bookmarked) or existing bookmarked dialog.

Comment 2

[limkokhole]

btw, may i know how to edit my post/comments ? I don't want to send new comment merely a single word typo.

Comment 3

[arni2033]

Thanks for filing this. I regularly run into the issue you described.

> So far so good because i can reuse the description, right ?
Actually, no. "Buffered" value replaces description provided by the site, which only brings confusion.
And it won't be saved unless you edit that "buffered" value somehow, so there's no sense in showing it

I personally doubt that Firefox team will ever fix this regression: 
1) it's quite hard to access description of current bookmarked page, and that is by_design
2) currently bookmarks panel is being actively destroyed (see bug 1219794 and connected regressions)
3) ... and complete themes that may be showing 'Description' field, will be killed too (bug 1222546)

This is regression from bug 951651. Regression range:
> https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0b202671c9e2&tochange=22a157f7feb7

Comment 4

[Marco Bonardo [:mak]]

this is the change:
-      this._initTextField("descriptionField",
-                          PlacesUIUtils.getItemDescription(this._itemId));
+      if (this._paneInfo.visibleRows.has("descriptionRow"))
+        this._initDescriptionField();

We init the description field only if it's part of the visibleRows, and that cannot be changed through a userChrome hack.
It's not exactly a regression, since it requires external code to be added to Firefox to cause the bug. An add-on could do that more properly than a userChrome hack.

The only possibility I see to fix this in the code, would be to change the visibleRows construction code to "try" hiding the element and then checking if it has been really hidden through getBoundingClientRect.
Though, I'm not sure it would work since the panel could still be hidden when the code runs, and then it would return wrong results.
If that's not feasible, I fear this may become a wontfix and an add-on would be required.

Comment 5

[Marco Bonardo [:mak]]

we're removing the description field