Hi @Cor, no repro, column field gets the focus for me, with:
Version: 5.4.2.2 (x64)
Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4
CPU threads: 4; OS: Windows 6.19; UI render: default; 
Locale: es-ES (es_ES); Calc: group

The column field is enabled in fresh and master. Writer puts the focus at the objects list/tree (which is btw not part of the tab sequence in Calc). Do you mean to harmonize this behavior?

Thanks Mario!
My summary was not clear. Does it make sense now?
I mean the old Navigator, not the one in the Side Bar, but docked.
Indeed, if floating, I have what you describe.

(In reply to Heiko Tietze from comment #2)
> The column field is enabled in fresh and master. Writer puts the focus at
> the objects list/tree (which is btw not part of the tab sequence in Calc).
> Do you mean to harmonize this behavior?

Yes, harmonizing makes sense and indeed including the list in the tab order!
thanks.

Confirming the issue for the docked Navigator (shift+ctrl+F10 is your friend). 

Please include the list with Sheets, Range, Database... in the tab sequence (ally issue) and focus this control having the active sheet selected when the Navigator is enabled per F5. That allows the user to just press Enter to jump back to the sheet.

@Cor, how are you getting the F5 second instance of Navigator deck to dock?

With 5.4.2.2 and recent master Windows builds, I can not.

A service for Stuart who never reads my comments:

(In reply to Heiko Tietze from comment #5)
> ... (shift+ctrl+F10 is your friend).

(In reply to Heiko Tietze from comment #7)
> A service for Stuart who never reads my comments:
> 
> (In reply to Heiko Tietze from comment #5)
> > ... (shift+ctrl+F10 is your friend).

:D, 

Actually, I had another installed application (Alertus Desktop) holding the <shift><ctrl>+F10 shortcut assignment for OS.  But, drag-to-dock does not work for this dialog--no attachment target gets shown.

(In reply to Cor Nouws from comment #3)
> I mean the old Navigator, not the one in the Side Bar, but docked.

There is no "old Navigator", just a second instance of the source as wrapped for use the Sidebar's deck (bug 73151#c14). 

That it does not receive focus when it is docked seems odd because when held in the Sidebar deck it _does_ receive the focus. I think this is not an easy hack and seems related to the fact that to the two instances are not kept in sync (i.e. movement and actions are independent).

It is annoying and maybe some simple connection needs to be made--but I still think the best way to "fix" this is to complete work on bug 85905 and have only one instance of the Navigator and a UI that behaves.

@Jim, in Calc the "secondary" <F5> Navigator when undocked takes focus on launch, but it does not when in docked state as in summary.

Otherwise the full sidebar Navigator deck in Calc does not take focus on launch, docked or floating.

Wouldn't expectation be for focus to be in Navigator on launch for both instances, in either state (docked or undocked)?

Sidebar -- in Calc the Sidebar instance of Navigator is well synced with the secondary <F5> instance.  But in Writer they are not so well joined. Is there something missing from the Writer instance of the Sidebar deck?

(In reply to V Stuart Foote from comment #10)

Hi Stuart, I was going to jump in on this one after seeing the untouched bug notification. Thanks for the invite!

We can make the Calc version of Navigator focus on any content in Navigator on initial showing for both the floating and docked mode. The Writer version content tree grabs focus on initial showing. There is a side effect to this that occurs in the sidebar which causes focus to be placed in the tree list the first time the Navigator deck is selected. Subsequent Navigator deck selection with mouse click does not place focus in the content tree but back to the document in the current master at the time of this post.  

When the F5 Navigator is undocked focus is in the undocked window but since the window itself is non active it causes a focus lock. To test this, place focus in the Column or Row spin box when the Navigator is docked, then undocking with Ctrl+Shift+F10. The floating/child window is not active which can be seen by the shaded title bar. Focus is locked in the spin box. A mouse click on the Navigator window title bar will show the cursor in the spin box or whatever content was focused when the window was undocked.

> Sidebar -- in Calc the Sidebar instance of Navigator is well synced...
I like the Sidebar pun! but I am unsynced on the well synced thing? :-)

(In reply to Jim Raykowski from comment #11)
> (In reply to V Stuart Foote from comment #10)

> > Sidebar -- in Calc the Sidebar instance of Navigator is well synced...
> I like the Sidebar pun! but I am unsynced on the well synced thing? :-)

Sorry, this is really a different issue--observing differences in the synchronization of control focus between the two Navigator panels (<F5> and in Sidebar proper) between the Calc implementation and the Writer implementation. In Calc the two will each refresh to follow the same focus. In Writer they are independent--no linkage between them so out of sync as far as the element with focus.

Hi Jim, Stuart,

(In reply to Jim Raykowski from comment #11)
> (In reply to V Stuart Foote from comment #10)

> We can make the Calc version of Navigator focus on any content in Navigator
> on initial showing for both the floating and docked mode. The Writer version
> content tree grabs focus on initial showing.
Fine for me, if it doesn't cause the same effect as in Writer: bug 49684.

(In reply to V Stuart Foote from comment #12)
> ...   In Calc the two will each refresh to follow the same focus.
> In Writer they are independent--no linkage between them so out of sync as
> far as the element with focus.

With content view for headings, Navigator in Writer should follow the selected part of text. For the rest, I don't see a need/advantage of the both versions to be in sync. Especially since I don't expect people to use the two at the same time, and if, it might even be an advantage that they are not synced?

Don't think we need more input from UX (and keyword was not set anyway), removing the ML.

Problem still the same in Version: 7.4.1.2 / LibreOffice Community
Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: nl-NL (en_US.UTF-8); UI: nl-NL
Calc: threaded