Closed Bug 422700 Opened 12 years ago Closed 11 years ago

Get bug 376238 fixed or disable images on drag feedback

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3

People

(Reporter: standard8, Assigned: asuth)

References

(Depends on 1 open bug)

Details

(Keywords: dogfood)

Attachments

(1 file)

Due to bug 376238, when dragging and dropping multiple messages on TB trunk Linux, unless the mouse is well placed, it is very difficult to work out where the mouse is when you are dropping messages.

I suggest we either get that fixed, or turn the nglayout.enable_drag_images off for Linux until that is fixed.

Either way, I think we should resolve it for TB 3.0a1.
Flags: blocking-thunderbird3.0a1?
Another possibility is to use a custom dragimage on Linux for messages, so that other drags aren't affected.
Flags: blocking-thunderbird3.0a1? → blocking-thunderbird3.0a1+
Keywords: dogfood
Status: NEW → ASSIGNED
Assignee: nobody → bugmail
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
If it's not fixed I'd recommend turning the option off until such time as it is.  Currently Evolution (default GNOME email client) doesn't do any special images for dragging so the behavior shouldn't be unexpected.
Use the interim solution preference on bug 376238 to disable image dragging by default for Thunderbird for the GTK2 widget back-end.  As a consolation prize, we get the default GTK2 stock icon.  (Note: There is no differentiation between dragging one/many.)

When bug 376238 is properly fixed, the preference will presumably be automatically mooted, although this fix should still then be removed.
Attachment #316166 - Flags: superreview?(dmose)
Attachment #316166 - Flags: review?(bugzilla)
Comment on attachment 316166 [details] [diff] [review]
disable drag images for GTK2 for thunderbird

Cancelling sr request; code in mail/ doesn't require superreview.  I now have review privs for mail/; marking this as r+ despite it being requested of Standard8 in the interest of unblocking an 3.0a1 bug.
Attachment #316166 - Flags: superreview?(dmose)
Attachment #316166 - Flags: review?(bugzilla)
Attachment #316166 - Flags: review+
Blocks: TB2SM
mail/app/profile/all-thunderbird.js 1.112
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
No longer blocks: TB2SM
Target Milestone: --- → Thunderbird 3
No longer blocks: 429821
Depends on: 429821
(In reply to comment #5)
> mail/app/profile/all-thunderbird.js 1.112

This checkin should be reverted now, per bug 429821 comment 8:
{{
David Bienvenu   2008-05-13 15:55:48 PDT

better to remove it from all-thunderbird.js, I think, thx.
}}
Bug 376238 is fixed, attachment 316166 [details] [diff] [review] needs to be backed out.
Status: RESOLVED → REOPENED
Flags: blocking-thunderbird3.0a2?
Resolution: FIXED → ---
Bug 376238 doesn't seem to be fixed-1.9.0.1, or even have a 1.9.0.x approval flag set, so backing this out would need to depend on a bug that doesn't yet exist, but if it did would probably be a dependency of bug 437643.
Flags: blocking-thunderbird3.0a2? → blocking-thunderbird3.0a2-
Depends on: 437643
So we're now building from comm-central right?

Phil/Andrew, please can one of you two confirm that we've picked up that bug fix from bug 376238, and hence we can back out the attached patch.
We do have the fix for bug 376238.  And bug 429821 shadows this workaround anyways.  I lack the privileges to back this out, should I generate a reverse patch to help?

n.b. that the fix on bug 376238 requires a compositing window manager, so we may not want to back out bug 429821's fix yet...
And there's no reason to believe that Tb and SM will release at the same time, or make the same decision about how many of their Linux users are using a compositing window manager and how badly to screw over the ones that aren't, so rather than having this bug reopened, which really wasn't ever the right thing, we actually need three bugs: one to consider reenabling drag images for Tb, one to make SM's pref only apply to SM (either only SM-with-mail, as it effectively is now, or all-SM), and one to consider reenabling for SM.
Status: REOPENED → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → FIXED
Depends on: 450971
Filed bug 450971 for reenabling in Tb; realized we don't need anything to make the mailnews.js pref SM-only, since there's plenty of things there that we override in all-thunderbird.js; leaving the question of whether to make SM's pref apply without mail, and when and whether to reenable in SM to SM folks.
I don't see a real difference on when the point comes where we can enable it for SeaMonkey and Thunderbird, as installing SeaMonkey without mail is not possible atm for normal users (only available as an option for people who compile themselves), we are 100% bound to enable it when it works for mail, so probably at the same time as TB does it.
You need to log in before you can comment on or make changes to this bug.