1777869 - Headers start from row 2 in the headers pane (add-on "Message Header Toolbar Customize" was installed before; userChrome.css)

Status: RESOLVED INVALID

(Thunderbird :: Message Reader UI, defect)

Description

[meso5]

Attachment: pane1.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

I upgraded to v102 and ran TB as usual expecting to see the usual headers pane.

Actual results:

From the moment I upgraded to v102, the first header in the header pane (From:) is displayed in the second row. This leaves a gap in the first row (see photo). The toolbar is displayed in the first row as normal. This happens when the width of the TB window is less than around 775 pixels, even when there is plenty of space available. When I increase width to around 775 pixels, From: moves where it should be (ie top of the headers pane).

Expected results:

The From: header should be in the first row of the headers pane.

Comment 1

[Alessandro Castellani [:aleca]]

I'm not able to reproduce this issue.
Thomas, does this happen for you?

Comment 2

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani [:aleca] from comment #1)

I'm not able to reproduce this issue.
Thomas, does this happen for you?

Nope. But reporter must be running an addon which may interfere here, as can be seen by the reduced number of icons on the screenshot of attachment 9283950 [details].

meso5, does this problem happen with ≡ > Help > Troubleshoot Mode…?

Comment 3

[meso5]

(In reply to Thomas D. (:thomas8) from comment #2)

Nope. But reporter must be running an addon which may interfere here, as can be seen by the reduced number of icons on the screenshot of attachment 9283950 [details].

The icons are hidden through a custom userChrome.css. Before I reported this I disabled all addons and the problem was still there.

meso5, does this problem happen with ≡ > Help > Troubleshoot Mode…?

Yes, it does. I would upload a new screenshot but it looks the same as the first one only this time the complete set of buttons are visible.

Comment 4

[Alessandro Castellani [:aleca]]

Would you feel comfortable to share your userChrome.css?
If you don't want to upload it here, feel free to send it to my email directly.

Comment 5

[meso5]

#header-view-toolbar toolbarbutton[disabled="true"],
#header-view-toolbar > #hdrReplyToSenderButton,
#header-view-toolbar > #hdrArchiveButton {
  display: none;
} 

I was getting the problem before I created a userChrome.css for the first time. I created the css file hoping that (a) by shortening the toolbar, there would be more space for the From: header to fit in the first row and (b) because the archive button is completely pointless to me. Shortening the toolbar have no effect, but From: moves up to where it should be if I hide the toolbar.

It may be relevant that I had 'Message Header Toolbar Customize' installed. This was incompatible with v102 and then I removed it completely. Not sure if it interfered with TB's settings.

Comment 6

[Alessandro Castellani [:aleca]]

It may be relevant that I had 'Message Header Toolbar Customize' installed. This was incompatible with v102 and then I removed it completely. Not sure if it interfered with TB's settings.

It might be, indeed.
I'm not sure if that add-on left some residual CSS that is causing the header to stack. We had some media queries before 102 to make that happen, but they've been removed.
The fact that you were able to specifically find that the problem appears below 775 pixels, makes me think that there might be some CSS or edited markup that triggers that UI wrapping.

Would you be able to do something a bit more advanced?

• Open the Developer Tools
• Make sure to be on the Inspector tab
• Select the #messageHeader and start inspecting its child elements, particularly the:
  • #headerSenderToolbarContainer
  • #header-view-toolbox
  • #expandedfromRow and its children

Let me know if you can spot some CSS declarations or media queries that are causing these elements to wrap.

Comment 7

[meso5]

Would you be able to do something a bit more advanced?

I got there and I can see the specific lines that refer to that toolbar in the header pane, padding etc but I can't tell which part, if any, is suspicious. I couldn't find a way to export that branch so I generated a massive screenshot if anyone is interested.

Comment 8

[Magnus Melin [:mkmelin]]

Please try the "Reset toolbars" option you get when opening Troubleshoot mode

Comment 9

[meso5]

(In reply to Magnus Melin [:mkmelin] from comment #8)

Please try the "Reset toolbars" option you get when opening Troubleshoot mode

Done and nothing changed.

Comment 10

[Thomas D. (:thomas8)]

Attachment: Reporter's screenshot from comment 7: xhtml markup of message header which displays the bug

Reporter's screenshot from comment 7: xhtml markup of message header which displays the bug

I can see an element in the header which does not exist in default Thunderbird:
<vbox id="compactHeadersBox"...>

Such injected elements may well cause the changed row arrangement of this bug.

Comment 11

[Thomas D. (:thomas8)]

(In reply to meso5 from comment #5)

It may be relevant that I had 'Message Header Toolbar Customize' installed. This was incompatible with v102 and then I removed it completely. Not sure if it interfered with TB's settings.

Meso,

• can you comment how you "removed it completely"?
• were you able to solve your problem described in this bug?

(In reply to Thomas D. (:thomas8) from comment #10)

Created attachment 9312695 [details]
I can see an element in the header which does not exist in default Thunderbird:
<vbox id="compactHeadersBox"...>
Such injected elements may well cause the changed row arrangement of this bug.

John,

• Is it possible that an add-on which has been completely removed can still have residual effects in Thunderbird?
• Specifically, what about "compactHeadersBox" which is in reporter's markup (see screenshot attachment 9312695 [details])? Could this survive even in Troubleshoot Mode?
• Could it help to start Thunderbird with -purgecaches command line parameter?

Ultimately, there's nothing here which points to a bug in Thunderbird, this is something which went wrong from reporter's add-ons and customizations -> invalid. If we cannot figure this out here, Thunderbird support might be another option.

Comment 12

[meso5]

(In reply to Thomas D. (:thomas8) from comment #11)

Meso,

• can you comment how you "removed it completely"?

I selected 'Remove' in addons. I did not just disable the addon.

• were you able to solve your problem described in this bug?

No, it's still there.

Comment 13

[John Bieling (:TbSync)]

Is it possible that an add-on which has been completely removed can still have residual effects in Thunderbird?

Experiment add-ons: Yes, when they manipulated preferences or the XULStore (or other permanent internal storages) and did not undo them on uninstall.

Specifically, what about "compactHeadersBox" which is in reporter's markup (see screenshot attachment 9312695 [details])? Could this survive even in Troubleshoot Mode?

Markup is not stored, but always modified/adjusted on add-on startup. I have never heard of a case where the cache injected code of uninstalled add-ons. The only thing I can remember is that XUL files part of add-ons sometimes have not been refreshed on add-on reload and the old XUL file was used, even though the add-on actually included a newer/different one. In those case --purgechaches did help.

Overall, this bug is really really strange. I have no idea what is going on :-( The extra vbox must be injected by something. It is definitely not in our source.