Controlled from the document canvas at
 
https://opengrok.libreoffice.org/xref/core/sw/source/uibase/docvw/HeaderFooterWin.cxx#125

with linkages back to UI and Insert menu controls, and modification of the Page Style dialog's Header and Footer tabs.

Don't see that it can be suppressed now.

But, if controls were to be suppressed on the document canvas (i.e. the click in area of header or footer), would there need to be more controls added to the Insert menu or the Page Style dialog?

Good Point. The Header/Footer menu provides settings, that you only can find in a well hidden sub menu in Page Style Modify menu. 
Looked at that way, some more controls need to be added in Insert Menu and/or Page style dialog.

I've also been bitten by the pop-up a lot, especially when zooming out to see multiple pages at once. Also, I find that it lags and glitches a lot relative to other elements of the UI.

Without the popup, perhaps shortcuts to insert/modify the the header and footer could be added to the context menu when clicking in the top/bottom margins of the page, or in the header/footer area when enabled. IMO this would be just as convenient, without the current annoyances.

The floating menu has not only the advantage of presenting functions but also shows very clear that you aren't in the document canvas anymore. While competitors require the user to double-click somewhere, remember that this space might be very small depending on the page settings. It's just the way how LibreOffice deals with the this function and I don't see a use case to disable it -> WFM.

Btw, you can insert a header/footer via Insert > Header and Footer > ...

Yes, of course, there are some advantages, no doubt.
But there are also (a lot of) problems, that occur with the header/footer pop-up.

For a detailed description, see first entry of this bug and Comment #3. Here a short list of issues:
• Poor handling and bad interactions when Pictures or Tables are at the top of the page.
• Chance of unintentional insert of a header/footer. That really annoys.
• It lags and glitches a lot relative to other elements of the UI.
• Problems with zooming out to multipage-view.
• Headers and footers are added normally just one time, but the pop-up menu appears every time. Is this really necessary?

And, with due respect Herr Tietze, I don't agree with your explanations.
1. I don't see, how the menu shows ›very clear‹ that you aren't in the document canvas. Why? Because it's blue and slow? What kind of justification is that? In my opinion it only presenting function and nothing more. 
2. You said, competitors require the user to double-click somewhere, and this space might be very small, depending on page settings. First, where is the problem? A double-click is definitely not unintended – in contrast to a single-click! And second, relating to the page settings, where is the difference to LibreOffice?? The LibO-User also have to click on the header/footer space. And this space could also be very small. When margin is set to 0,01 cm you also have problems with the pop-up menu.
3. You don't see a use case to disable it. I can tell you:
  3.1. You just don't want to insert any header or footer.
  3.2. You are using other ways to insert a header, for example:
    3.2.1. Navigation bar → Page.
    3.2.2. Menu Insert → Header/Footer.
    3.2.3. Navigation bar → Styles → Page Styles.

So, finally...
1. I don't want you to abolish it. I just want a option to suppress it, that it don't always pop up when I single-click in margin space. It is really annoying. It lags. There are so many other good ways to insert a header/footer.
2. The menu Insert → Header/Footer is very sparse. An addition with controls, what the floating menu contains, would be useful (see Comment #1).

I fully agree with Christoph Bartz. Close to hand menus are for frequently used actions, not for something you do, at best, a couple of times for each file or, even worst, a couple of times for each template.

But perhaps the worst part of this "feature" is that it goes in the same line of the "page panel" in the sidebar and other similar features: it hides from new users the fact that pages are managed through styles. I've been using, and explaining how to use, Writer for the last 20 years, and IMHO it's becoming more difficult, not easier, to explain to new users why page styles are their friend and not their foe.

Okay, too many options aren't a solution in general (if not "hidden" in the advanced registry) but in that case we could add "[x] Show floating header/footer menu" at Tools > Options > Writer > View > View (defaulting to on).

Let's see if a dev is interested in it. Without Stuart's comment I'd say it's an easy hack but apparently it isn't.

I would be very grateful for this!
A [x]-option in Tools > Options > Writer > View > View would be very nice.
A hidden option in Tools > Options > LibreOffice > Advanced > Expert Configuration also would suffice.
In any case – Thank You!

(In reply to Heiko Tietze from comment #7)
> Without Stuart's comment I'd say it's an easy hack but apparently it isn't.

It *is* an easy hack. Starting from the place mentioned by Stuart (putting a breakpoint there), one can easily see the call stack, and find a suitable place to put a check for a config setting.

(In reply to Mike Kaganski from comment #9)
> It *is* an easy hack. Starting from the place mentioned by Stuart (putting a
> breakpoint there), one can easily see the call stack, and find a suitable
> place to put a check for a config setting.

That's the simple part but there is no good place for on/off. At least I cannot see a simple solution.

(In reply to Heiko Tietze from comment #10)

Sigh, I'd prefer to not solve easy hacks for "newbies", because - well, easy hack is expected to allow a newcomer to do something not too dull, and at the same time not too difficult, but...

The top of call stack at the breakpoint:

> swlo.dll!SwHeaderFooterWin::SwHeaderFooterWin(SwEditWin * pEditWin, const SwFrame * pFrame, bool bHeader) Line 138
> 	at c:\lo\src\core\sw\source\uibase\docvw\headerfooterwin.cxx(138)
> swlo.dll!VclPtr<SwHeaderFooterWin>::Create<VclPtr<SwEditWin> &,SwPageFrame const * &,bool const &>(VclPtr<SwEditWin> & <arg_0>, const SwPageFrame * & <arg_1>, const bool & <arg_2>) Line 135
> 	at c:\lo\src\core\include\vcl\vclptr.hxx(135)
> swlo.dll!SwFrameControlsManager::SetHeaderFooterControl(const SwPageFrame * pPageFrame, FrameControlType eType, Point aOffset) Line 107
> 	at c:\lo\src\core\sw\source\uibase\docvw\framecontrolsmanager.cxx(107)
> swlo.dll!SwPageFrame::PaintDecorators() Line 3679
> 	at c:\lo\src\core\sw\source\core\layout\paintfrm.cxx(3679)
> swlo.dll!SwRootFrame::PaintSwFrame(OutputDevice & rRenderContext, const SwRect & rRect, const SwPrintData * const pPrintData) Line 3191
> 	at c:\lo\src\core\sw\source\core\layout\paintfrm.cxx(3191)
> ...

Of course, there's no reason to change something below SwRootFrame::PaintSwFrame, because this method is generic enough (it isn't specific to creation of the controls, but paints the whole frame, as its name suggests). None of its callers would have good knowledge whether (or how) to create those controls.

SwRootFrame::PaintSwFrame itself doesn't directly create those controls, but calls SwPageFrame::PaintDecorators, which does many other kinds of things - so no reason to place the check in SwRootFrame::PaintSwFrame, too: too far from the actual place of controls creation.

The latter (SwPageFrame::PaintDecorators) calls SwFrameControlsManager::SetHeaderFooterControl, which is specifically created to do what we want to manage. So - it's natural to think the two places for performing the check: either in places where SwFrameControlsManager::SetHeaderFooterControl is called (grepping for "SetHeaderFooterControl" gives only two such places, both in the same function) - so just calling it conditionally; or inside SwFrameControlsManager::SetHeaderFooterControl, doing the check and exiting early.

These two options are both acceptable, and a newbie could propose a change with any of them (and then we'd discuss pros and contras in the gerrit change)... just telling "I can't" and me writing all this means spoiling the whole easy hack, effectively because me doing all that the newcomer was expected to do.

Created attachment 145589 [details]
Tentative UI

Working on the topic but I'm not totally happy with the text. The new option is on a different level as "Display" so I added "User Interface", which feels not right. UI sounds more like menu, toolbar etc. And "Show header/footer menu" might also have room for a better wording. Any ideas?

(In reply to Heiko Tietze from comment #12)
UI seems not correct, you're right, Heiko. I would add it to 'Display'. It's like 'Tooltips on tracked changes' a helping tool to make something easier for the user. Wording can be 'Header/footer menu while hovering over border to page content' analog to 'Helplines while moving'. Or we can move it to 'Guides' ...

heiko tietze committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4e4c8a71756da952686cdd682c6132413959dc21

tdf#118621 - Optionally disable floating header/footer menu

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

There is now a UNO command, customizable for being placed in the toolbar and available in the menu by default under Insert > Header & Footer > [x] Use header/footer menu.

Thanks for discussion and reviews.

I love options :) - thanks Hieko!

Hi Heiko,
the release notes says it's enabled by default -> https://wiki.documentfoundation.org/ReleaseNotes/6.2#Writer

However, if I do, rm -rf instdir/user/ && instdir/program/soffice it's disabled by default

Version: 6.2.0.0.alpha1+
Build ID: 7da3947535d1b3aac23b3d0a72e94396960ee751
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded

Could you please double-check ?

Yes, it seems that disabled is the default setting now. Default should be an activated 'Use header/footer menu'.

To be pedantic, I don't like that this option is in the 'Insert' menu. It has nothing to do with 'Insert' and--if it really must be in a menu--it should be part of the 'View' menu. Why it's not in the Options dialog?

Version: 6.2.0.0.alpha1+ (x64)
Build ID: ae9f37ba753519ae4a2ae6384d052d417359602f
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-23_02:03:22
Locale: de-AT (de_AT); Calc: CL

*** Bug 66652 has been marked as a duplicate of this bug. ***

(In reply to Commit Notification from comment #14)
> heiko tietze committed a patch related to this issue.
> It has been pushed to "master":
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=4e4c8a71756da952686cdd682c6132413959dc21
> 
> tdf#118621 - Optionally disable floating header/footer menu
> 
> It will be available in 6.2.0.
> 
> The patch should be included in the daily builds available at
> http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
> information about daily builds can be found at:
> http://wiki.documentfoundation.org/Testing_Daily_Builds
> 
> Affected users are encouraged to test the fix and report feedback.

Hi Heiko,

I noticed while working on some header/footer bugs that when "Use header/footer menu" is off the escape key does not return the cursor to the main document window as it does when it is on. The reason is SwViewShell::IsHeaderFooterEdit() always returns false when "Use header/footer menu" is off. This isn't so bad because the cursor can still be returned to the main document using the keyboard by Ctrl+PageUp when in the header or Ctrl+PageDown when in the footer. These are the default shortcut keys assigned to uno commands To Header (.uno:JumpToHeader) and To Footer (.uno:JumpToFooter).
  
Here is where escape key input is handled when cursor is in header footer edit window:

sw/source/uibase/docvw/edtwin.cxx
void SwEditWin::KeyInput(const KeyEvent &rKEvt)
...
    else if ( rKEvt.GetKeyCode().GetCode() == KEY_ESCAPE &&
            rSh.IsHeaderFooterEdit( ) )
    {
        bool bHeader = bool(FrameTypeFlags::HEADER & rSh.GetFrameType(nullptr,false));
        if ( bHeader )
            rSh.SttPg();
        else
            rSh.EndPg();
        rSh.ToggleHeaderFooterEdit();
    }
...
    
Here are other areas where IsHeaderFooterEdit() is used which may cause differences of behavior:
        
sw/source/core/frmedt/feshview.cxx
// Test if there is a object at that position and if it should be selected.
bool SwFEShell::ShouldObjectBeSelected(const Point& rPt)
{
...
    // Don't select header / footer objects in body edition and vice-versa
    SwContact* pContact = static_cast<SwContact*>(pObj->GetUserCall());
    if (pContact && !pContact->ObjAnchoredAtPage() )
    {
        const SwPosition& rPos = pContact->GetContentAnchor();
        bool bInHdrFtr = GetDoc()->IsInHeaderFooter( rPos.nNode );
        if (IsHeaderFooterEdit() != bInHdrFtr)
        {
            bRet = false;
        }
    }

sw/source/uibase/docvw/edtwin.cxx
void SwEditWin::Command( const CommandEvent& rCEvt )
{
...
    // Don't trigger the command on a frame anchored to header/footer is not editing it
    FrameControlType eControl;
    bool bOverFly = false;
    bool bPageAnchored = false;
    bool bOverHeaderFooterFly = IsOverHeaderFooterFly( aDocPos, eControl, bOverFly, bPageAnchored );
    // !bOverHeaderFooterFly doesn't mean we have a frame to select
    if ( !bPageAnchored && rCEvt.IsMouseEvent( ) &&
        ( ( rSh.IsHeaderFooterEdit( ) && !bOverHeaderFooterFly && bOverFly ) ||
        ( !rSh.IsHeaderFooterEdit( ) && bOverHeaderFooterFly ) ) )
    {
        return;
    }

Good point with escape. Do you want to to push the patch (referring to this ticket) or should I gain the laurels?

(In reply to Heiko Tietze from comment #21)
> Good point with escape. Do you want to to push the patch (referring to this
> ticket) or should I gain the laurels?

I haven't looked at how to patch this, just the cause. You are welcome to take all of the glory :-) I am happy to review, do, or provide code pointers.

heiko tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/68e47d3c7c2de280b3353cfbe86e1a03bb723bfa%5E%21

tdf#118621 - Optional header/footer menu

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.