[V1] - QInput - keep autofocus working inside keep-alive scenario

[ibrainventures]

What kind of change does this PR introduce?

• [ X] Bugfix
• [ X ] Feature
• Documentation
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes
• [ X] No

The PR fulfills these requirements:

• It's submitted to the dev branch (or v[X] branch)
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• It's been tested on a Cordova (iOS, Android) app
• It's been tested on a Electron app
• Any necessary documentation has been added or updated in the docs or explained in the PR's description.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to start a new feature discussion first and wait for approval before working on it)

Other information:

[pdanpdan]

I'm not very sure this is the right place to do a focus
I would rather think it would be a better idea to refocus from a container - but I would need some use case examples

[ibrainventures]

Actually we are doing many Form-rework for simpler step-by-step forms with only one input element.
Those are switched inside q-tab-panels with keep-alive.

For simplicissity we are "sliding in the keyboard" on those panels.
(and there we find the issue, when go back and forward that the autofocus is missing) ..
(and by ref we are not getting the context for the keyboard slide-in)

[ibrainventures]

May it is better included inside the QField.js Source .. Don´t have the overview, which Form components are all
using a autofocus option. Or by the Focusmanager, but may the context for the automatic slide-in Keyboard (which
is the feature) effect is than broken. Dont´t know .. may you can hold this "issue" in your repropository
and close this PR .. (i am actually still running on a heacy patched 1.12 - 1.17.4 Frankenstein quasar ;-)) )

[pdanpdan]

@ibrainventures what patches do you use for your branch?

[rstoenescu]

Enhancement will be available in Quasar v2.4.11 and v1.17.6

[ibrainventures]

@pdanpdan

export default async ({ Vue }) => {
  Vue.component('QLayoutPlus', QLayoutPlus)
  Vue.component('QDrawerPlus', QDrawerPlus)
  Vue.component('QPagePlus', QPagePlus)
  Vue.component('QPageContainerPlus', QPageContainerPlus)
  Vue.component('QHeaderPlus', QHeaderPlus)
  Vue.component('QFooterPlus', QFooterPlus)
  Vue.component('QDialogPlus', QDialogPlus)
  Vue.component('QCardPlusMenuRight', QCardPlusMenuRight)
  Vue.component('QCardPlusMenuRightSlide', QCardPlusMenuRightSlide)
  Vue.component('QTabPlus', QTabPlus)
  Vue.component('QTabsPlus', QTabsPlus)
  Vue.component('QUploaderPlus', QUploaderPlus)
  Vue.component('QUploaderPlusAddTrigger', QUploaderPlusAddTrigger)
  Vue.component('QIntersectionPlus', QIntersectionPlus)
}

Based on a 1.12.13 freezed Source there were 3 main topics to work-around:

Layout + UI Comps.: limit the emit-noise / pollution

Uploader : Same Filename (picture.jpg) can´t be selected twice

Dialog : using the https:// github.com/ FL3NKEY /scroll-lock instead of the ios - body technique / upscroll ..

All have side-effects on the SSR or allround-functionality .. So they are not PR compatible,
and resist now in a big monorepro .. (which was not my favor ..)

[ibrainventures]

@rstoenescu and @pdanpdan

Thank you very much for this fast solution 👍

[ibrainventures]

Background:

Uploader : Same Filename (picture.jpg) can´t be selected twice

The Smartphone Cam (Ios) name a captur-ed Image always with the same filename.
So it breaks when i will upload 1+ fresh made pictures ..

[pdanpdan]

QUploader should be fixed in this: #11610

[ibrainventures]

Hi @pdanpdan ...
i dont want to make you going nuts .. :-) :-)

Now with a workin autofocus on keepAlive-ed Pages, there comes on some Browsers
e.g. firefox the effect, that a vue-router (saved) and forced scrolling position cannot
be reached, because of the preventScroll parameter / browser implement state.

According to the
https://html.spec.whatwg.org/#focus-management-apis

there is a option for the .focus method.

If using:

elem.focus([{ preventScroll: true }])` -------------> EDITED : NOPE

the vue-router is respected.

To not hardwire this feature, this should be controllable ..

element.focus([ { preventScroll: true } ])

    Moves the focus to the element.

    If the element is a browsing context container, moves the focus to its nested browsing context instead.

    By default, this method also scrolls the element into view. Providing the preventScroll option and setting it to true prevents this behavior.

[ibrainventures]

Hmmm ..
After some testing, this effect is not so easy to stop ..
Sometimes it scrolls, sometimes it blocks .. sometimes it does not re-focus ...
crazy ...

But .. good to know that there is a option for this behaviour .. May it is also
the culprit for some other effects ..

[pdanpdan]

:P :)

[ibrainventures]

okay .. i catched the control / browser differences over the effects and made a PR.
The usage of the preventScroll solved some really nasty effects inside our keep-alive tab panels.

The most nasty thing, was the transition distortion ..:

The 2 effects with focus / autofocus (not only on keep-alived elements)

Effect A: vue-router, savedPosition is not respected

Effect B: Transition breaks immediatly (distortion during sliding ..)

------------------ Chrome Android: "Has" effect A (opens the Keyboard) + effect B
with the preventFocusScroll option:
-> no (side effect) on effect A (opens the Keyboard nicely)
-> effect B solved by preventFocusScroll

------------------ Chrome Windows: Has effect B
with the preventFocusScroll option:
-> solved by preventFocusScroll

------------------ Firefox windows: has effect A + B
with the preventFocusScroll option:
Both effects are solved with preventFocusScroll

------------------ iOS safari: has only effect B
-> Ignores ? the preventFocusScroll by Design / no change of behaviour