If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Social API moves focus into the url bar whenever I get a new message

RESOLVED FIXED

Status

()

Firefox
SocialAPI
--
major
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: robarnold, Unassigned)

Tracking

Trunk
All
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Haven't seen this on Windows but it happens all the time to me on OSX. I disabled the integration on one of my machines and I haven't seen it on that machine since. It doesn't seem to always occur but I believe it happens when you get an IM on a window that is minimized (I could not repro on a maximized window). My sidebar is off, but the chat and notification jewels are enabled.
Shane, nothing here leaps out at me, and you both have a mac and recently looked at focus issues, so adding you to CC.  Rob has indicated he has disabled the entire feature due to how disruptive this is, and assuming other users feel the same, we should probably treat this as a priority.
Severity: normal → major
My build isn't working right now to do some testing, but I am guessing this has something to do with the focus advancement happening in socialchat.xml.  Perhaps when the chat is minimized, there is nothing to advance into, an error occurs, and focus gets reset.
Created attachment 714177 [details] [diff] [review]
Don't attempt to focus a minimized chat.

A similar problem happens on Linux - focus doesn't go to the URL bar, but seems to go to the tab itself.

The problem, as I understand it, is that the focusManager can't find any focusable elements in the minimized chatbox, so selects another element to focus instead.  A simple fix for this specific issue is to have socialchat.xml explicitly check for the selectedChat being minimized, and not attempting to set focus when that is the case.  (FWIW, I explicitly tried focusing the iframe and iframe.contentDocument.documentElement, but the same problem exists.)

This patch does exactly that.  It still leaves us with the problem that if the chat is not minimized, focus gets "stolen" to the chat window, but that already has a bug and is quite a different problem.

Gavin - any thoughts?
Attachment #714177 - Flags: feedback?(gavin.sharp)
Comment on attachment 714177 [details] [diff] [review]
Don't attempt to focus a minimized chat.

This looks good to me.
Attachment #714177 - Flags: feedback+
Hmm, advanceFocusIntoSubtree is really mostly just a backwards compat/convenience wrapper around nsIFocusManager::MoveFocus. MoveFocus allows you to pass flags controlling the behavior, like FLAG_NOPARENTFRAME. I wonder whether we should just do something like that instead, to also handle the case where the chat is unminimized but doesn't contain and focusable children.
Comment on attachment 714177 [details] [diff] [review]
Don't attempt to focus a minimized chat.

This is a reasonable work-around for the immediate issue, though.
Attachment #714177 - Attachment is patch: true
Attachment #714177 - Flags: feedback?(gavin.sharp) → review+
The patch in bug 831489 covers this issue too, right?
Depends on: 831489
I just verified things work as expected on Linux with the patch to bug 831489
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.