1848526 - Bookmark title has incorrect truncation

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Alistair Buxton]

Attachment: Screenshot showing the bug.

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

1. Install Livemarks extension (which creates and removes bookmarks dynamically using the webextension API.)
2. Follow an RSS feed using it.
3. Wait.

Actual results:

Livemarks creates bookmarks in folders on the bookmarks toolbar. Sometimes, when it is manipulating the titles of these bookmarks, the displayed title is truncated to the same length as the previous bookmark in the folder. See screenshot for an example. The second bookmark in the menu is truncated (ends with "...") and is the same length as the first one, even though the window is much wider.

Expected results:

The bookmark titles should not be truncated unless they are too long to fit in the window.

What seems to be happening is that the RSS feed updates, so Livemarks needs to shuffle all the bookmarks in the folder down by one, and then somehow the wrong string is used to calculate metrics.

Other Information:

1. This is a regression. It seems to have started happening some time around FF113.

2. This is not a problem with Livemarks - it has no control over how bookmarks get rendered in the browser.

3. It isn't the RSS feed either. I wrote the feed generator myself and I know it isn't truncating anything.

4. The final proof that this is a Firefox bug: if you have two windows open it is possible that the truncation looks different between them. Opening a new window always shows the full titles, until Livemarks needs to add a new one.

See https://github.com/nt1m/livemarks/issues/451 for more detailed explanation of the observations with screenshots.

Comment 1

[Alistair Buxton]

I made a mistake in the description: for "previous title" substitute "next title".

ie in the screenshot, "Candy Vs Hydra..." is being truncated to the same length as "Ninja Turtle Sudoku", because that is the bookmark that previously occupied the top slot. It should not be truncated more than necessary to fit in the window.

One other thing: I do use userchrome.css tweaks, but I reproduced this issue with them disabled.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Tim Nguyen :ntim]

I recommend bisecting this with mozregression in case you haven't: https://mozilla.github.io/mozregression/quickstart.html

Comment 4

[Dão Gottwald [:dao]]

Not sure where this belongs, but probably not themes. Could be an issue with the label truncation handling. A regression range would help.

Comment 5

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (118.0a1/20230816215210), Beta (117.0b8/20230815180041) and Release (116.0.3/20230815173142) under Windows 10 x64 and Ubuntu 22.04 LTS.

I added https://www.reddit.com/r/AskReddit/new/.rss into Livemarks as the feed gets updated frequently and it should trigger the issue eventually. Even so, with the lowest 1 minute update interval in Livemarks, I still reproduced the issue very inconsistently.

See the attached screenshot for more details.

I tried running a mozregression but it found a, I believe, wrong bug: Bug 1824304 - Fix PiP window type hint after bug 1823350. r=stransky. Differential Revision: https://phabricator.services.mozilla.com/D173677

I’ll attempt to run the mozregression again, although it will be difficult since results are very inconsistent as far as I can tell.

Comment 6

[Alex Cornestean]

Attachment: 2023-08-17_11h53_23.png

Comment 7

[seamusriordan]

I've been having the same issue for some months now and it is also inconsistent.

Comment 8

[Rob Wu [:robwu]]

(In reply to Alex Cornestean from comment #5)

I’ll attempt to run the mozregression again, although it will be difficult since results are very inconsistent as far as I can tell.

Have you managed to identify a reliable regressor?

Comment 9

[Alex Cornestean]

I just returned from PTO and tried the mozregression again.

I think it’s going to take a bit longer to come up with a regressor as I spent the better part of 2 hours trying to reproduce the issue at least once as per the steps from Comment 5 and still haven’t managed to reproduce it….

It’s very inconsistent, as the reddit posts that appear, which the add-on retrieves and bookmarks, have varying title lengths and certain title length conditions have to be met in order for the issue to be triggered.

I’m still at it and as soon as I get some results I’ll update the report.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:rpl, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hey dao, If I'm reading the bug and the screenshots correctly (the one attached on github looks more clearly the bookmarks popup menu attached to a bookmark folder visible in the bookmarks toolbar, see the screenshot attached here: https://github.com/nt1m/livemarks/issues/451#issue-1755247955) the ellipsis are added automatically to the bookmarks listed in the popup menu and applied through a crop="end" added to the menu entries labels (and the extensions API doesn't directly control those labels, it should be just allowing the extension to manipulate the bookmarks as stored inside our Places database).

I'm not sure how the ellipsis added as a side effect of crop="end" are being handled (nor where exactly in our internals they are handled), but the fact that comment 0 is mentioning explicitly that the same bookmarks is rendered fine in one window and wrongly truncated with ellipsis in another one is making me wonder if the issue may be triggered by the extension more as a side-effect, and that maybe the popup window where the ellipsis are wrong should have been more explicitly refreshed to ensure the labels with crop="end" are going to be recomputed, wdyt?

(e.g. I'm even wondering if there would be any chance for a similar bug to be hit with bookmarks sync-ed over Firefox sync, instead of being added dynamically by an extension through the extension API)

Comment 12

[Thomas Bertels]

The smallest regression window I could get is https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1e022917b1abe226ddb2e5b87979f345e4da5a05&tochange=906260e46b192bed1b9c55bcbe14d8faeae543a0 (2023-03-16)

Could it be https://hg.mozilla.org/integration/autoland/rev/c15f0fb1c92375ea751b3916a4c25a34403f21b2 from bug 1809084?

Beyond that, mozregression-gui stopped working without error (see bug 1857759).

Comment 13

[Tim Nguyen :ntim]

bug 1809084 seems quite likely. Emilio, can you take a look?

Comment 14

[Emilio Cobos Álvarez (:emilio)]

I couldn't reproduce on Nightly using the steps in comment 5 and a few refreshes. The ellipsis here is just plain text-overflow: ellipsis, this is the relevant rule:

https://searchfox.org/mozilla-central/rev/abbea4195b00e82af2ae9abaafc31e4b4ec4f8c0/toolkit/content/xul.css#185-191

If this is reproducible, it should also be reproducible with regular html / css.

Thomas, do you have more reliable STR than comment 5? If so mind sharing so that I can investigate? Thanks

Comment 15

[John Norman]

Attachment: 2023-10-08 20_07_13-Parent process Browser Toolbox.png

This bug also affects me. I've tried to inspect Firefox using the Browser Toolbox, but the fact that you can't easily use the element picker on a menu item makes it somewhat difficult.

However, the big thing I've noticed is that the <label class="menu-text">'s ::before element is sized incorrectly. I don't know why this happens, but in my attached image, the ::before element has a width of 70.4833. The <label> has a width of 328. If I cause a reflow by unchecking one of the CSS rules for the ::before element and re-enabling it, the ::before has a correct width and the truncation is gone.

It is pretty easy to notice if you open up many different windows. After a couple refreshes of the RSS feeds, each window will have different truncation in each RSS feed.

Comment 16

[Thomas Bertels]

Attachment: Layout.png

Unfortunately, I didn't find anything better than setting the refresh to 1 minute and checking the menu from time to time.

I used the Browser Toolbox to inspect the menu when I reproduce the bug, but the only thing that changes is the layout.

Comment 17

[John Norman]

One thing to also note is that Livemarks will change the name of a bookmark when you visit the link. When the name of the bookmark changes, it causes the dimensions of the element to be recalculated and the truncation gets removed; I even changed the bookmark sort order using the Manage Bookmarks menu and that also caused a recalculation. Maybe the Bookmarks API is somehow skipping a recalculation of the dimensions?

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.

Comment 19

[Marco Bonardo [:mak]]

Unfortunately I don't think the bookmarks code can do much here, as we only modify the DOM, without setting any width. It seems more like a widget/layout bug.
Though without more reliable steps it may be hard to debug.

Comment 20

[Mike Conley (:mconley) (:⚙️)]

Investigation in this bug seems to suggest that this is a bug in Layout, so moving there.

Comment 21

[Thomas Bertels]

Thanks to Zeid Zabaneh's help in bug 1857759, I could resume the bibisection and managed to reduce the regression window to only one commit: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=526b311af03354ed0f06ec7572b486a51bc884f6&tochange=c15f0fb1c92375ea751b3916a4c25a34403f21b2
So bug 1809084 is definitely the culprit.

To reproduce it, I used https://www.reddit.com/r/AskReddit/new/.rss mentioned above, but also http://lifehacker.com/rss.
I set the refresh rate to 1 minute (not sure if it's really important) and let the browser sit there for up to one hour, checking regularly by opening the personal toolbar livemarks menus, without clicking on any entry.

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1809084

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1809084

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jfkthame, could you have a look please?

For more information, please visit BugBot documentation.

Comment 25

[Dianna Smith [:diannaS]]

setting NI to the author of the regressor in #c23

Comment 26

[Emilio Cobos Álvarez (:emilio)]

Without better STR / test-case to debug this I don't think investigating this is a super high priority / a great use of time, unfortunately.

I can try to create a dummy extension that changes stuff just in the right way... Hopefully that way I can then debug it with less than two hours between runs. I'll give this a shot, but if someone has the cycles or knows the relevant extension APIs already and can give that a shot that'd be great.

S3 seems appropriate here.

Comment 27

[Tim Nguyen :ntim]

Hi Alistair / Thomas,

Do you have some feeds where this bug reproduces somewhat consistently for you?

I tried https://www.youtube.com/feeds/videos.xml?channel_id=UCmHfCD8c8CmjlyWa8d4GObg as feed but couldn't reproduce on my side (on macOS).

If you do have feeds that consistently reproduce for you, one thing that could be helpful for Emilio is to export your bookmarks from the library (Menu > Bookmarks > Manage Bookmarks > (double arrow icon) > Export bookmarks to HTML

Comment 28

[Thomas Bertels]

To reproduce it, I used https://www.reddit.com/r/AskReddit/new/.rss mentioned above, but also http://lifehacker.com/rss.
I set the refresh rate to 1 minute (not sure if it's really important) and let the browser sit there for up to one hour, checking regularly by opening the personal toolbar livemarks menus, without clicking on any entry.

Comment 29

[John Norman]

It can easily happen in just a few minutes for me. Just make sure you have multiple browser windows open and have your Bookmarks Toolbar enabled and visible with Livemarks installed. After a few refreshes of the RSS feed (which causes Livemarks to add and delete bookmarks from the toolbar) you can just open the menu in the Bookmarks Toolbar on each browser window and you will probably see one of them with a bad layout.

Comment 30

[Emilio Cobos Álvarez (:emilio)]

So I haven't been able to repro anything like that using comment 28 and 29, to the point I start thinking it might have to do with my setup somehow... Which OSes are you?

I created http://github.com/emilio/bug-1848526-playground to play around with this extension API but I haven't managed to find a set of update() / create() calls that trigger the bug.

Comment 31

[John Norman]

Attachment: 2023-11-15 20_41_35-.png

:emilio, I am using Firefox Beta on Windows 11. I modified your extension to trigger the bug for me.
https://github.com/LoneBoco/bug-1848526-playground

The browser is better at updating the layout if you are constantly checking the menu. For the screenshot I've attached, I had two browser windows opened and I let it sit there for 15 seconds or so before I opened the menu on my Bookmarks Toolbar. If the refresh happens while the window is open, the layout is usually corrected; that's why I set the update interval to 10 seconds. It gives you a window of time to check the bookmarks between the refreshes.

Comment 32

[John Norman]

Sorry, I meant to say that if the refresh happens while the MENU is open, the layout is usually corrected. If you sit there with the menu open watching the bookmarks refresh, you probably won't catch the problem. You have to wait for a refresh to happen with the menu closed. Then you can check the menu in each opened Firefox window to see if any of them bugged out.

Comment 33

[Emilio Cobos Álvarez (:emilio)]

(In reply to John Norman from comment #32)

Sorry, I meant to say that if the refresh happens while the MENU is open, the layout is usually corrected. If you sit there with the menu open watching the bookmarks refresh, you probably won't catch the problem. You have to wait for a refresh to happen with the menu closed. Then you can check the menu in each opened Firefox window to see if any of them bugged out.

Thanks, that's great to know, and that pointed at the problem quite easily, see the attached patch :)

Comment 34

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1848526 - Clear descendant intrinsics too when opening a popup. r=dholbert,tnikkel,#layout

This is probably testable, but I don't know how we'd make the test
reliable (we haven't found particularly reliable STR yet, see comments).

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f69ae42e4d0b
Clear descendant intrinsics too when opening a popup. r=tnikkel,layout-reviewers

Comment 36

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/f69ae42e4d0b

Comment 37

[Alex Cornestean]

Verified as Fixed. Tested on the latest Nightly (121.0a1/20231119091854) and Beta (120.0/20231113165053), as well, for comparison reasons, under macOS 11.3.1 and Windows 10 x64.

I used the extension linked in Comment 31 and checked both Beta 120 (without the fix) and Nightly 121 (with the fix). On Beta, the issue still occurs, while on Nightly bookmark titles are correctly truncated, confirming the fix.

For more details, see the attached screenshots.

Comment 38

[Alex Cornestean]

Attachment: Beta 120 incorrect truncation.png

Comment 39

[Alex Cornestean]

Attachment: Nightly 121 correct truncation.png