1652290 - Spell Check dialog and many others open at position (0,0) of first monitor regardless where the calling TB window is

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect, P2)

Description

[[e-mail]]

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

Steps to reproduce:

Working with two monitors, Thunderbird positioned on 2nd monitor. Write and send email, which invokes spell check dialog.

Actual results:

Dialog box is always positioned in the top-left corner of monitor 1. This is true for other dialog boxes as well and any fix should apply to positioning of all dialog boxes. This is especially problematic when "Remote Desktop" is running on monitor 1, because the dialog box is hidden. The sent email seems to hang, because there is no visible element showing input is required to continue.

Expected results:

All dialog boxes should be positioned relative to the Thunderbird parent window, or at a minimum on the same monitor as the parent window.

Comment 1

[Wayne Mery (:wsmwk)]

Did this also happen prior to version 79 or version 78?

Comment 2

[[e-mail]]

Sorry, I don't have a good answer. I believe it worked before 79.

Comment 4

[Alex Ihrig [:Thunderbird_Mail_DE]]

Regression window between 72 Beta 3 and 73 Beta 1

Comment 5

[Wayne Mery (:wsmwk)]

quite a lot of change in that range https://hg.mozilla.org/releases/comm-beta/pushloghtml?fromchange=THUNDERBIRD_72_0b3_RELEASE&tochange=THUNDERBIRD_73_0b1_RELEASE&full=1

Comment 6

[Alex Ihrig [:Thunderbird_Mail_DE]]

Maybe this one

https://hg.mozilla.org/comm-central/rev/bb22d7034b6f

Bug 1606032

Comment 8

[Michael Bowen]

For me, this worked prior to version 78 but not thereafter. I only have one screen, but I have my Windows taskbar set at the top of the screen, and it's resized to contain two rows of icons. So this new spell check behavior is annoying because the second row of icons hides part of the spell check dialog box, include the drag bar across the top. So to move the dialog so I can see it, I have to resize my taskbar to one row (to expose the draggable zone at the top of the dialog), move the dialog to another location on the screen, and then resize my taskbar again back to two rows. If you can't get the dialog to stay in the Thunderbird window, it would be nice if it could at least remember the last place it was dragged to the next time it opens.

Comment 10

[Thomas D. (:thomas8)]

There are two related problems here:

1. The spell check dialog (and other dialogs, as someone claimed?) opens on monitor 1 even if composition is on monitor 2.
2. After dragging the dialog to the right monitor, its position isn't persisted (which could be a workaround) for next time.

We have already duped both problems here, guess that's ok, some reports make no distinction anyway.
We can always re-open one of the dupes if we fix one problem without the other.
Opening on the wrong monitor is quite nasty, especially if the other monitor with the composition window runs on remote control as described, so the primary monitor with the dialog is inaccessible, and sending messages can appear blocked. That's almost S2!

Persistence is minor but opening on a different monitor is very wrong!

Comment 12

[bugzilla_aw]

I wrote up the below, but then found this post on the same issue with the Check Spelling dialog. Adding anyway in case any info is useful.

I'm running Thunderbird (currently 78.4.3 (32-bit), but issue has persisted across at least several versions) on a Windows 10 Pro 20H2 19042.630 PC (but issue has persisted across several Win10 versions).

I have a two monitor system
Monitor #1 2560x1440 secondary, running Thunderbird
Monitor #2 3840x2160 primary

When doing an Options/Check Spelling on an email message, even though TB and the message is on Mon #1, the Check Spelling dialog always appears in the upper left corner of Mon #2. This is even after I (repeatedly) move that Check Spelling dialog to the secondary Mon #1.

Other dialogs that originally appeared in the upper left corner of Mon #2 but now appear when reopened on Mon #1 after I moved them = New Event, New Task, Address Book, Message Filters, Activity Monitor, (maybe others I moved and forgot about).

TB's "About" dialog appears on Mon #1, the same one as running TB.

I would think that TB should open its assorted dialogs on the same "active" monitor as TB rather than the "primary" monitor, esp. if those aren't the same. Or at least remember dialog positions if those are moved to a specific monitor -- unless that monitor is no longer present, in which case dialogs should open on an actual monitor.

Comment 13

[TREMBLAY,Bernard]

Hi,

I had not found this 1652290 when I opened 1676473 one week ago.
This generally happens in development when an "old" routine which opens a new windows which is related to a parent do not checks if there are several screens and desktop configuration. Then the routine do not find the position of the current parent (not found) and returns (0,0).

Best regards
Trebly

Comment 14

[Sam]

I also started having this problem after I upgraded from 68.12.1 to 78.5.0. I am now on 78.6.0 and the problem still occurs.

Comment 15

[Tony DiBenedetto]

I have this problem but it only started for me after updating to 78.6.1 64bit. I only have one monitor but it's a 32" 4K with Win10 set to 150% Scaling.

Comment 17

[Magnus Melin [:mkmelin]]

Is this actually a duplicate of bug 531833?

Comment 18

[Michael Bowen]

@Magnus, it sounds like the same symptom but I only started seeing this a few months ago, not 11 years ago, which is when 531833 was opened. Some other code change might have re-triggered the problem more recently.

Comment 19

[Anje]

Tested this on Windows 10 OS
I have two version running symultaneously - version 68.12.1 and 78.9.0
Using one monitor screen

Version 68.12.1 if I move 'spell check' window from top left to top right, close and reopen, it remembers the location.
xulstore : chrome://editor/content/EdSpellCheck.xul":{"spellCheckDlg":{"screenX":"720","screenY":"-55"}}}

Version 78.9.0 if I move 'spell check' window from top left to top right, close and reopen, it does not remembers the location and keeps opening on top left of screen.
xulstore: chrome://editor/content/EdSpellCheck.xul":{"spellCheckDlg":{"screenX":"-78","screenY":"-33"}}

Test:
Exit Thunderbird and edit xulxtore.json to say same as version 68.12.1 eg: "screenX":"720","screenY":"-55" and save file.
Upon restart, saved info is overwritten and back to usual problem. So not a workaround by this method.

Support Forum user reports same issue.
https://support.mozilla.org/en-US/questions/1330931

Comment 20

[Magnus Melin [:mkmelin]]

But the spell checking dialog is modal (can't be moved), and centered to the compose window. At least on trunk. What am I missing? For persistence, could have been bug 1698143.

Comment 21

[Richard Marti (:Paenglab)]

You are missing Windows.

Comment 22

[Magnus Melin [:mkmelin]]

So modal are stll movable on Windows? It's all opened as modal AFAICT, https://searchfox.org/comm-central/search?q=EdSpellCheck.xhtml&path=mail

Anyway, someone could re-check trunk/beta to see if bug 1698143 fixed it.

Comment 23

[Richard Marti (:Paenglab)]

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

So modal are stll movable on Windows? It's all opened as modal AFAICT, https://searchfox.org/comm-central/search?q=EdSpellCheck.xhtml&path=mail

Yes, it's opened as modal but opens always on top left. And is movable.

Anyway, someone could re-check trunk/beta to see if bug 1698143 fixed it.

It doesn't remember the position.

Comment 24

[Magnus Melin [:mkmelin]]

I guess "centerscreen" could be added to all the arguments, regardless.
But I see now, bug 1698143 only fixed persistence for calendar. mail/ should need similar treatment...

Comment 25

[Ian Eales]

"Centerscreen" is a band-aid and not a fix.
Just FYI, I used to use 4 monitors for other apps, code, application, Dox.
Child windows need to initially be on the same screen as the application, remember where they were moved AND check if the desktop is the same size as last use, moving to the closest active screen if not as when using a laptop in a dock with multiple monitors and then not.

Comment 27

[ISHIKAWA, Chiaki (back from day job exhibition event.)]

Attachment: Spell check dialog shown at (0,0) position

Funny, I thought having this spell checker at (0,0) position was a feature.
I think this has been like this for at least a few years if I recall correctly.

Attached is the screen dump of a mail composition this morning.
The upper left corner is the (0,0) position, i.e., the upper-left corner of my screen.

Now, since I don't use multi-screen, I did not experience the type of problems which people with multi-screen had. So although the placement was a bit strange, but I never realized this was a bug.

I bet a lot of Windows users didn't think twice when the spell checker dialog appears at the upper left and and simply got on with it. (I simply did not regard this a bug although I did find it a bit odd for the first few times, but now I have accepted as "C'est la vie".)
I only realized this could be an unintended behavior when I realized that someone filed this bugzilla when I was checking the list of bugs found during 78 testing posted by Wayne.

In a few months we will be shipping version 91. If you have a few minutes to help, it would be cool to > fix or close a few more of the remaining open bugs from tb78found meta bug.
Remaining open bugs: https://bugzilla.mozilla.org/showdependencytree.cgi?id=1644037&hide_resolved=1
tb78bound meta bug: bug 1644037

Comment 28

[marty]

I'm working with large multiple large screens and multiple application windows, and I have TB located on a screen to my right. When I compose and send a message, I have to mouse way over to the left extreme of a screen to my left to complete the send. Since the mail window may be a 45 degree head turn to my right, I may not even see the little window pop up 90 degrees to the left of it in my peripheral vision. It may overlay another open, similarly colored window, making it easy to miss. Then I have to mouse back to the right screen to continue working with TB. That's a lot of wasted movement and time.
If an app spawns a dialog window, why shouldn't it should default to overlay or be adjacent to the parent window?

Thank you to all the developers!

Comment 29

[Michael Bowen]

My issues (in Windows 10) are that (1) I have my taskbar at the top of the screen (personal preference; it's easier for me to mouse upward to open a new app than downward, and it helps keep my head level more of the time), (2) I've stretched the taskbar vertically to accommodate two rows of Quick Launch icons (my work requires me to use numerous apps and I don't like to clutter the main taskbar (or my desktop) with inactive tasks because there are so many of them, so I use QL even though Microsoft would probably love to obsolete it), and (3) due to visual issues I need to read open TB in full-screen mode (a "Normal Window" is just too small). So TB occupies my entire Windows desktop when in use.

When I open the Spell Check dialog on my laptop (which has a typically sized laptop screen), the top left corner of that dialog is placed where the upper left corner of the Windows desktop would have been located IF I had a normal one-row taskbar at the bottom of the screen (like most people do). Because I have a two-row taskbar at the top of the screen, the upper portion of the Spell Check dialog is obscured by the fat taskbar, and so I have to move the dialog every time I want to see the spelling suggestions when it finds typos, as these are typically hidden.

Ironically, I discovered that if I simply click the bottom edge of the dialog box, it magically re-positions itself in the expected and desired manner (i.e., its upper left corner moves downward to the upper left corner of the TB window and becomes fully viewable). If there were a programmatic way for a developer to simulate a mouse click on the bottom edge of the dialog box right after it opened, that might constitute a quick fix to the problem at least for some users.

Comment 30

[jimgill2002]

I don't know why, after many months, we're still debating when this happened or if it was intended as a feature. It's a STUPID bug. I know of no other Windows application that throws up a dialog box so far away from where the app itself is and where you can't reposition it and have that relative position saved.

Thunderbird didn't do this before and I can't think of any reason why stuffing this dialog way up in the corner is a Good Idea.

Just fix the damned thing!

Comment 31

[Anje]

What is required is that by default it opens positioned top left, BUT if user moves to eg: top right, then this should be remembered and the information kept in the xulstore.json file, so that Thunderbird remembers this and from then onwards always opens in that position.
In other words exactly as it did prior to version 78.
I still have a version 68.12.1 and it works perfectly. It stays exactly where I positioned it years ago.
68.12.1 was the last version to work correctly.

I auto have Thunderbird on left, Write window opens to the right of that window and Spellcheck opens to the right of that window.
Nothing is on top of anything nor obscured by anything.
I'm running 78.11.0 to read emails generally and so I'm up to speed to offer help in Support Forum.
Creating emails in version 78* is not as desirable for various reasons including this spellcheck window bug, that I use 68.12.1 for sending emails. Hence how I know it was the last to work as expected.

Even if you move the window to the right, this new position is not entered in the xulstore.json file which continues to display the default.
It always says: xulstore: chrome://editor/content/EdSpellCheck.xul":{"spellCheckDlg":{"screenX":"-78","screenY":"-33"}}

This had to be a deliberate change in code when creating version 78. Was there some thinking/reasoning behind this that brought about the change?
Is there any reason why it cannot be fixed before the next main release?

Comment 33

[Thomas D. (:thomas8)]

Attachment: Screenshot: Programmer's World...

@all:

Thank you very much everyone for your valuable user feedback, and my apologies for the significant annoyance which this has caused and still is...

Let me assure you that this bug is well-understood, and we are going to fix it in due time, hopefully soon.

This bug originates from a technical restructuring in the code around all dialog elements (so it's not just the spell check dialog).

There are two aspects of the problem:

• A Dialog will first pop up at position 0/0 of the first screen, even if the underlying Thunderbird window is on another screen. That's not just wrong and annoying, it might make the dialog inaccessible when user does not have access to the first screen, e.g. in remote control scenarios.
• A Dialog will not remember its new position even after user relocates it to a better position on the right screen. Iow, the new dialog position is not persisted. That's very annoying, as the dialog will stubbornly keep popping up in the initial 0/0 position and users will have to reposition it each and every time. It's also error-prone, as users may not even notice the dialog on another screen, which will get them into undefined and seemingly unresponsive UI states.

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

But I see now, bug 1698143 only fixed persistence for calendar. mail/ should need similar treatment...

I have just filed the missing bugs to fix persistence in the three other areas of our code.
Fixing persistence will fix the biggest part of this bug.

(In reply to Anje from comment #31)

This had to be a deliberate change in code when creating version 78. Was there some thinking/reasoning behind this that brought about the change?

Well, no! This has never been an intentional change. It's just human error, an oversight originating from the respective dependants of meta bug 1585545, which is purely technical in nature:
Restructure all <xul:dialog> usages such that they are not the top level element.
Unfortunately, dialog persistence was broken in the process, and we need to fix it.

Please bear with us while we are working on a fix. You know, programmers may find themselves between a rock and a hard place (see attached cartoon):

• If it's broken: WHY!?
• If it works: WHY!?

Multiplied by the unlimited number of bugs we are working on... with limited time and manpower!

Is there any reason why it cannot be fixed before the next main release?

I'm confident that we'll get this fixed for the next main release, Thunderbird 91.
Once again, thank you for your feedback, which enables us to make Thunderbird better!

Comment 34

[Magnus Melin [:mkmelin]]

I think this is now fixed (bug 1717235). Can someone confirm with 91.0b1 once that's out?

Comment 35

[Thomas D. (:thomas8)]

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

I think this is now fixed (bug 1717235). Can someone confirm with 91.0b1 once that's out?

TLDR: This will be better, but not fully fixed by bug 1717236.

Depending on scenario, bug 1717236 (sic) may improve the situation as we'll now persist the dialog size and position of the spellcheck dialog. So after moving it into the correct position once, it will stay there for next time (need to check for how long - current composition only or subsequent compositions, too?).

However, I am not seeing anything on the relevant part of the patch which would fix the first half of the problem, namely that with Thunderbird e.g. on screen 2, dialogs like spellcheck will open (first time) at position 0,0 of screen 1, which may not even be accessible (as some users have reported wrt remote control sessions limited to one screen - see comment 0). From an UX perspective, opening a dialog on a different screen first time is pretty wrong - as users have reported here, even if you have access to the screen where the dialog popped up, you may not even find it there because it's so unexpected, then TB UI looks unresponsive, which is especially bad at send time when spellcheck pops up for those who have that setting.

Comment 36

[Thomas D. (:thomas8)]

Let's fix the initial position of the dialog here, as comment 0 and many dupes report exactly that.
At least for spellcheck dialog - we could fix other dialogs in another bug.
As for positioning with "centerscreen", see critical comment 25.

Comment 37

[Magnus Melin [:mkmelin]]

Well, that part isn't a regression. I don't think it's Thunderbird problem, but much deeper down in platform code.

Comment 38

[Magnus Melin [:mkmelin]]

Bug 1005620 and bug 1005618 as well as dependencies seem to have it all covered. Nothing to do for Thunderbird here.

Comment 39

[marty]

This issue has traversed so many bug reports it's hard to keep them straight.
Am I reading this one correctly as a closed issue? Please explain!

This continues to be a significant ergonomic and operational problem. Other Windows programs that spawn dialog windows do not behave this way.

Comment 40

[Wayne Mery (:wsmwk)]

(In reply to marty from comment #39)

This issue has traversed so many bug reports it's hard to keep them straight.
Am I reading this one correctly as a closed issue? Please explain!

This bug is closed, but it doesn't mean the problem is resolved. The solutions must come via the bugs mentioned in comment 38.
Perhaps it would be more correct to dup this bug to one of those bugs.

Comment 41

[marty]

It seems like neither of those adequately addresses the problem.
Bug 1005620 is MAC specific and is related to the main app window (a different issue).
Bug 1005618 was lowered in priority for lack of activity (likely because of related bug threads like this one).

This Bug Report, # 1652290 seems to have the most comprehensive information and should be the survivor.
I don't understand Magnus Melin's statement that there's "Nothing to do for Thunderbird here."

My apologies that as a user, not a programmer, I have nothing to contribute towards a solution, and I would like to express appreciation for all of you who are!

Comment 42

[Magnus Melin [:mkmelin]]

The problem as reported originally was fixed. There are problems around which monitor things open on, but those are problems that need to be fixed on in the platform code.

Comment 43

[Thomas D. (:thomas8)]

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

The problem as reported originally was fixed.

Can you elaborate where the remaining problem dialogs open at (0,0) of first monitor when they show for the very first time was fixed?
I've just tested this on several virgin installs (Win10, 94.0a1 (2021-09-21) (64-bit), 91.1.1 (64-bits)), and the very first time the spellcheck dialog still gets opened at 0,0 of first monitor although the composition window was open on the second monitor (combined desktop). Even the composition window itself actually opened on another unrelated monitor. Interestingly, some other dialogs from Insert menu of composition seemed to open at least closer to the left side of the parent window.

Per comment 0 and many more (e.g. my comment 33, comment 35, TLDR: comment 36), this bug reports two aspects of the problem, but afasics we've fixed only persistence, but not initial position. As users have pointed out, that's still unexpected, unhelpful, can make users believe that their composition window is no longer responding, and in some cases iiuc may even prevent access to the dialog on a distant monitor reserved for remote access. Note that composition window may be on monitor 4, so it's weird when the spell check dialog then opens on monitor 1.

There are problems around which monitor things open on, but those are problems that need to be fixed on in the platform code.

• Are you expecting that those two bugs about the initial position of the FF/TB main window (Bug 1005620 and bug 1005618) are going to fix initial position of all dialog windows as well?
• Are we sure that this can only be solved in platform code, e.g. looking at your own comment Comment 24 where you considered using "centerscreen"?

Imho, given the strong user interest in this issue (7 duplicates plus many comments here), we should try to ensure that this gets fully fixed, regardless of its origin.

Comment 44

[Anje]

Feedback:
Using Win 10 and TB version 91.1.1
One monitor screen.
Thunderbird positioned in left half of screen.
Click on 'Write' and move to central right
upon first use.....
click on 'spelling' and it opens in far left 0,0 over Thunderbird as expected.
Move to far right.
Close , open, close several Write windows and on each time open Spelling - the Spelling window opens where I positioned it on far right.
Tested exiting and reopening TB and all still correct.
"chrome://messenger/content/messengercompose/EdSpellCheck.xhtml":{"spellCheckDlg":{"screenX":"845","screenY":"0"}}}

Moved Spelling window and data is remembered:
"chrome://messenger/content/messengercompose/EdSpellCheck.xhtml":{"spellCheckDlg":{"screenX":"663","screenY":"4"}}}

Many Thanks to those who worked on this. I can confirm for my single monitor all is working perfectly ok.

Comment 45

[Thomas D. (:thomas8)]

(In reply to Anje from comment #44)

Many Thanks to those who worked on this. I can confirm for my single monitor all is working perfectly ok.

Sure, thanks & welcome, indeed we've fixed dialog position persistence on the bugs which I filed.
However, with multiple monitors the problem remains that a dialog which is opened for the first time (i.e. doesn't have persisted position yet, or persistence data reset) will open on 0,0 of the first monitor, regardless where the parent window is. So e.g. composition might be on monitor 4, but spellcheck (first time) will open on monitor 1. Not nice when sending, users can think composition is no longer responding, and other access issues wrt remote sessions. Any dialog window should be first shown on the same screen as the parent window.

Comment 46

[Magnus Melin [:mkmelin]]

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

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

The problem as reported originally was fixed.

Can you elaborate where the remaining problem dialogs open at (0,0) of first monitor when they show for the very first time was fixed?

That was not the problem originally reported.

• Are you expecting that those two bugs about the initial position of the FF/TB main window (Bug 1005620 and bug 1005618) are going to fix initial position of all dialog windows as well?

Remains to be seen, but surely prerequisites at least.

• Are we sure that this can only be solved in platform code, e.g. looking at your own comment Comment 24 where you considered using "centerscreen"?

It's platform dependent, you could try adding it to the features at https://searchfox.org/comm-central/rev/54966cc7991a76e73762ddbb37aaaac3478291a7/mail/components/compose/content/MsgComposeCommands.js#1126 and see if it changes anything. On linux this is not a problem: even now the spell check is modal + centered over the compose window.