Scrollbar of folder pane can be detached from UI element after viewing message with embedded image

RESOLVED FIXED in Thunderbird 52.0

Status

defect
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: jorgk, Assigned: mkmelin)

Tracking

({regression})

Trunk
Thunderbird 52.0
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Daily 52.0a1 (2016-11-11) (64-bit)

STR:
Click in the folder pane scrollbar to convince yourself that the scrollbar cannot be dragged to the left or right.

Open a new composition and copy/paste an embedded image from another message.

Click in the folder pane scrollbar again. It can now be moved to the left and right resulting in the display of a "STOP" traffic sign to indicate that it can't be dropped there. Moving the scrollbar with the cursor is now impossible.

Very weird.

I'm tipping that bug 1315480 is the culprit here since it changed the way images are inserted from other messages. No idea why that would affect XUL elements though.
OK, I was wrong, it's much simpler.

STR2:
One off preparation:
Create a folder which contains a single message that contains an embedded image.
Go to this folder and view the message.

Steps to check the problem during regression search:
Restart TB so it starts again in that folder. View the message.
Now the folder pane scrollbar has become detachable.

Forget the previous STR. No new message needed, no copy paste needed.

Alice, can you find us the regression. I'd say it's very recent since I have only recently noticed this behaviour.
Flags: needinfo?(alice0775)
Summary: Scrollbar of folder pane can be detached from UI element after image insertion → Scrollbar of folder pane can be detached from UI element after viewing message with embedded image
Suspect :
c8666b9f31bc	Magnus Melin — Bug 1315480 - avoid copying imap/mailbox urls as the aren't usable outside Thunderbird. Copy as data urls instead. r=jorgk
Thanks. I backed this out locally and it didn't fix anything. Magnus change is about copying an image. In my STR2 from comment #1 there is no copying involved. Just open TB to the folder with the message with the embedded image and it's already broken.

I don't think a C-C change caused this. Can you narrow it down on M-C?
Flags: needinfo?(alice0775)
I cannot build Tb. 
|python client.py checkout| fails on win10 due to unknown reason...
Flags: needinfo?(alice0775)
You don't need client.py. Just do |hg pull -u| on C-C and in the mozilla/ sub-directory. You'd be bisecting in the Mozilla directory anyway.
More regression search:
I can confirm that
Last Good :
20161110030323
https://hg.mozilla.org/comm-central/rev/497715ac1050e631b825a2401dd7383af129f7ce
https://hg.mozilla.org/mozilla-central/rev/336759fad4621dfcd0a3293840edbed67018accd
is indeed still good.
https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=497715ac1050e631b825a2401dd7383af129f7ce

Coincidentally my local M-C is a few days old and still at 336759fad462.

My C-C rev is further than 497715ac1050e631b825a2401dd7383af129f7ce.

That would indicate that the problem was introduced in C-C.

I'll check it further.
Damn, I don't know what I did wrong before. Stepping from C-C 1d2132213242 to C-C c8666b9f31bc shows the bug.

So the culprit is bug 1315480. Sorry Alice, I got it wrong. Magnus, can you please fix this.
Blocks: 1315480
Flags: needinfo?(mkmelin+mozilla)
Not exactly sure about the symptom you describe (maybe it's not the same? I think it is) but this seems to fix the problem I see.
Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
Flags: needinfo?(mkmelin+mozilla)
Attachment #8810075 - Flags: review?(jorgk)
Comment on attachment 8810075 [details] [diff] [review]
bug1317031_drag_scrollbar.patch

Review of attachment 8810075 [details] [diff] [review]:
-----------------------------------------------------------------

Yep, don't work your magic on UI elements ;-)

::: mail/base/content/mailWindow.js
@@ +69,5 @@
>    // For copy, the data of what is to be copied is not accessible at this point.
>    // Figure out what images are a) part of the selection and b) visible in
>    // the current document. If their source isn't http or data already, convert
>    // them to data URLs.
> +  

White-space ;-)
Funny, you told me once how to set myself up to avoid this.
Attachment #8810075 - Flags: review?(jorgk) → review+
Yeah, forgot a qref before submitting...

https://hg.mozilla.org/comm-central/rev/82f47febc327f5487158ed2a09331e195ba71ae2 -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 52.0
Blocks: 1317049
Just for the record: This could be dragged into a new compose window ;-(

<tree id="folderTree" class="plain" flex="1"
  hidecolumnpicker="false" persist="mode" mode="smart"
  keepcurrentinview="true" context="folderPaneContext"
  disablekeynavigation="true"
  ondragstart="gFolderTreeView._onDragStart(event);"
  ondragover="gFolderTreeView._onDragOver(event);"
  ondblclick="gFolderTreeView.onDoubleClick(event);"
  onselect="FolderPaneSelectionChange();" hidehscroll="true"
  clickthrough="never" focusring="true" hidevscroll="true"><br>
</tree>
You need to log in before you can comment on or make changes to this bug.