av9ash/GitBugs huggingface dataset:
Bug: Custom margin affects fixed scale when printing PDF file
Status: UNCONFIRMED
Priority: --
Created: 2025-02-24 17:04:23+00:00
Resolved: 2025-02-26 11:45:08+00:00

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

Steps to reproduce:

Open a PDF in Firefox, for example: https://pdfobject.com/pdf/sample.pdf

Open the print dialog.

Set the document scale to 100% (or any other fixed value).

Change from standard margins to custom margins.

Increase the size of the margins, for example set the top margin to 75mm.



Actual results:

The PDF gets scaled inversely to the margin size, i.e. larger margin results in smaller scale of PDF content.

The scale dialog still retains the previously set scale value, independent of the resulting scale of the document.

No other file types seem affected by this issue. I have tried JPG files, SVG files and regular webpages.


Expected results:

Changing the margins should not affect the scale of the document when scale is set to a fixed value.
Bug: Allow callouts to be dismissed by Esc even if they're not focused
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-02-24 19:17:59+00:00
Resolved: 2025-02-27 22:01:32+00:00

Right now callouts can only be dismissed by Esc if they're focused, and if you create a callout with no interactive elements, it won't be auto-focused, locking keyboard users out. This isn't the end of the world, since you'd only create a callout with no interactive elements if you gave it `autohide: true`, and then you'd just click outside of the callout. Users that can't enter mouse inputs to dismiss the callout most likely are keyboard-only users due to visual impairment, so might not even notice the callout exists, depending on the current screen-reading situation. I'd also like to audit the screen-reading situation as part of this bug, and make some other minor adjustments relating to the [login status advisory callout](https://docs.google.com/document/d/1Ny1D2J5M7SD6aa403bsQ2Tkq_yqwdruClGiTvKN5RDQ/edit).
Bug: Intermittent TV browser/components/customizableui/test/browser_customization_context_menus.js | disabled state for .customize-context-moveToPanel - Got false, expected true
Status: NEW
Priority: P5
Created: 2025-02-24 19:30:04+00:00
Resolved: 2025-03-04 14:44:51+00:00

**Filed by:** agoloman [at] mozilla.com
**Parsed log:** https://treeherder.mozilla.org/logviewer?job_id=496365825&repo=autoland
**Full log:** https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ScsWp-JoQxCSxNG27MTnEw/runs/0/artifacts/public/logs/live_backing.log
**Reftest URL:** https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ScsWp-JoQxCSxNG27MTnEw/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1

---
```
[task 2025-02-24T18:38:16.795Z] 18:38:16     INFO - TEST-PASS | browser/components/customizableui/test/browser_customization_context_menus.js | menuitem should match .customize-context-moveToPanel selector - 
[task 2025-02-24T18:38:16.796Z] 18:38:16     INFO - Buffered messages finished
[task 2025-02-24T18:38:16.797Z] 18:38:16     INFO - TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_customization_context_menus.js | disabled state for .customize-context-moveToPanel - Got false, expected true
[task 2025-02-24T18:38:16.797Z] 18:38:16     INFO - Stack trace:
[task 2025-02-24T18:38:16.798Z] 18:38:16     INFO - chrome://mochikit/content/browser-test.js:test_is:1654
[task 2025-02-24T18:38:16.798Z] 18:38:16     INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/head.js:checkContextMenu:475
[task 2025-02-24T18:38:16.798Z] 18:38:16     INFO - chrome://mochitests/content/browser/browser/components/customizableui/test/browser_customization_context_menus.js:titlebar_spacer_context:159
[task 2025-02-24T18:38:16.798Z] 18:38:16     INFO - chrome://mochikit/content/browser-test.js:handleTask:1170
[task 2025-02-24T18:38:16.798Z] 18:38:16     INFO - chrome://mochikit/content/browser-test.js:_runTaskBasedTest:1242
[task 2025-02-24T18:38:16.799Z] 18:38:16     INFO - chrome://mochikit/content/browser-test.js:Tester_execTest:1383
[task 2025-02-24T18:38:16.799Z] 18:38:16     INFO - chrome://mochikit/content/browser-test.js:nextTest/<:1153
[task 2025-02-24T18:38:16.799Z] 18:38:16     INFO - chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:SimpleTest.waitForFocus/<:1058
[task 2025-02-24T18:38:16.799Z] 18:38:16     INFO - TEST-PASS | browser/components/customizableui/test/browser_customization_context_menus.js | menuitem should match .customize-context-removeFromToolbar selector - 
```
Bug: AMO shows all markup tags of the HTML in my dictionary page
Status: RESOLVED
Priority: --
Resolution: INCOMPLETE
Created: 2025-02-24 22:11:30+00:00
Resolved: 2025-02-28 19:02:56+00:00

Heya,

I really don't know where to report this.

All the tags at AMO in the description of my add-on appear on the page and do nothing:
https://addons.mozilla.org/addon/british-english-dictionary-2

Please move this bug to the correct place if necessary.

Thank you!
Bug: Importing ExperimentManager has side-effects
Status: NEW
Priority: P4
Created: 2025-02-24 22:35:24+00:00
Resolved: 2025-02-24 22:35:24+00:00

Importing ExperimentManager.sys.mjs has side-effects; it will instantiate a global ExperimentManager instance that registers pref listeners. This is really only a problem for unit tests, but it is quite frustrating to deal with.
Bug: Remove aRequestToken parameter from CancelWithError()
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-02-25 01:23:04+00:00
Resolved: 2025-02-27 22:01:36+00:00

Per [D239396](https://phabricator.services.mozilla.com/D239396#inline-1325109), all callers should be passing `Nothing()`, so we can just remove the parameter.

(this will probably be fixed as a part of bug 1949834, fyi)
Bug: [macOS][Voiceover] Follow up on tab groups color additional VO focus square
Status: NEW
Priority: P3
Created: 2025-02-25 06:39:35+00:00
Resolved: 2025-02-27 12:15:04+00:00

**Found in**
* Nightly 137.0a1 (2025-02-24) 

**Affected versions**
* Nightly 137.0a1 (2025-02-24) 
* Beta 136.0b9

**Affected platforms**
* macOS

**Preconditions**
* Have voiceover active

**Steps to reproduce**
1. Access the create/manage tab group panel
2. Press tab to focus the color choices

**Expected result**
* There is one focus over the selected color

**Actual result**
* There is an additional fixed focus on the top left of the first color

**Additional Notes**
- Follow up on Bug 1949415
- The additional VO focus square seems to be offscreen if the window is closer to the upper part of the screen
Bug: Firefox crashes on agent timeout when ResultTimeout is set to 1
Status: RESOLVED
Priority: P2
Resolution: DUPLICATE
Created: 2025-02-25 09:16:31+00:00
Resolved: 2025-02-25 23:08:00+00:00

**Found in**
* 137.0a1 (2025-02-24)



**Affected versions**
* 137.0a1 (2025-02-24) 








**Tested platforms**
* Affected platforms:  Windows 10x64
* Unaffected platforms: Ubuntu 24, macOS


**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
* Create a distribution folder inside the Firefox folder and paste the policies-4.json to it and then rename it to policies.json
* set "TimeoutResult": 1 in policies.json file
* DLP Agent is running: `.\content_analysis_sdk_agent.exe --user --toblock=.*\d{3}-?\d{2}-?\d{4}.* --towarn=.*warn.* --delays=10`

**Steps to reproduce**
* Open Firefox and perform clipboard paste.



****Expected result****
* Firefox does not crash.

**Actual result**
* Firefox crashes.


**Regression range**
*  Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2cf34b3c9e6115e24043da1a5e48d3e272d37d4d&tochange=0af7a39fb3e13a48ef366fdb2532896cdf7a119f 
* Possible regressor: bug 1949166

**Additional notes**
* Attached a screen recording.
* This is a recent regression and we don’t know how often this will be reproduced in a real case scenario but I will mark this as high impact ([fidefe-quality-foundation?]).
Bug: Content is not allowed after choosing to use content with ResultTimeout set to 1
Status: RESOLVED
Priority: P3
Resolution: DUPLICATE
Created: 2025-02-25 09:45:47+00:00
Resolved: 2025-02-25 23:07:34+00:00

**Found in**
* 137.0a1 (2025-02-24)



**Affected versions**
* 137.0a1 (2025-02-24) 








**Tested platforms**
* Affected platforms:  Windows 10x64
* Unaffected platforms: Ubuntu 24, macOS


**Preconditions**
* Download the DLP test assets from https://drive.google.com/file/d/1yjqVRuxdKV3WnO7D2wzMgDXBuYBxUgVw/view
* Create a distribution folder inside the Firefox folder and paste the policies-4.json to it and then rename it to policies.json
* set "TimeoutResult": 1 in policies.json file
* DLP Agent is running: `.\content_analysis_sdk_agent.exe --user --toblock=.*\d{3}-?\d{2}-?\d{4}.* --towarn=.*warn.* --delays=10`

**Steps to reproduce**
* Open Firefox and perform the drag-and-drop action or upload.
* Choose to use content.



****Expected result****
* Content is allowed.

**Actual result**
* Nothing happens.


**Regression range**
*  Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2cf34b3c9e6115e24043da1a5e48d3e272d37d4d&tochange=0af7a39fb3e13a48ef366fdb2532896cdf7a119f 
* Possible regressor: bug 1949166

**Additional notes**
* Attached a screen recording.
* On the clipboard paste Firefox crashes (see bug 1950306)
Bug: Grouping indicator outline for dragged tab persists even when it won't create a new group
Status: NEW
Priority: --
Created: 2025-02-25 15:01:55+00:00
Resolved: 2025-03-04 14:45:33+00:00

STR:
1. Drag a tab over the first tab so that it shows the grouping indicator without it repositioning on latest Nightly 137.0a1 with `browser.tabs.groups.enabled = true`.  
2. Slowly drag the tab to the left so that the underlying first tab moves to second position.

Expected:
Dragged tab loses grouping indicator outline when it won't create a new group when dropped.

Actual:
Grouping indicator outline persists on dragged tab even though dropping won't create a new group.

Only dragging to the right (towards underlying tab) after clearing underlying tab resets the grouping indicator outline.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7d81a21559b6ea215ae9c163e436c9265ff9cb02&tochange=8e7552d63987c85bac8abde9f91cea1d584905b8

Regressed by Bug 1945788.
Bug: Sidebar collapses in expand on hover mode when trying to access tab right-click menu
Status: NEW
Priority: P2
Created: 2025-02-25 16:17:48+00:00
Resolved: 2025-02-26 20:04:38+00:00

First reported by a connect user - see video [here](https://www.youtube.com/watch?v=Dr92JmE6aNI) - if the sidebar is expanded, right-clicking on a tab in the vertical tabstrip collapses the launcher whereas it should stay open.
Bug: If one file upload is BLOCKed by DLP agent, allow the other files through
Status: NEW
Priority: --
Created: 2025-02-25 16:51:07+00:00
Resolved: 2025-03-04 21:09:25+00:00

(this is by request from a vendor)

If the user selects multiple individual files to upload, FIrefox should allow any files that get the ALLOW response to go through.

If the user selects a folder to upload, Firefox should continue the current behavior where if any file is BLOCKed, they all are.

This should cover clipboard paste, file picker, and drag and drop.
Bug: Hover state for "delete" in manage tab groups should be grey
Status: NEW
Priority: P3
Created: 2025-02-25 16:58:03+00:00
Resolved: 2025-03-04 15:47:56+00:00

**Steps to reproduce [can add screenshots or video recordings for reference]:**

1. Create a tab group
2. Right-click on the tab group label to open the "Manage tab group" panel
3. Hover over "Delete"


**Expected behavior [What should have happened?]:**

Hover state for "Delete" should be the same hover colour as the rest of the list items (grey)

**Actual behavior [What actually happened?]:**

Hover state is a different colour (red)
Bug: Impossible to deactivate TLS_CHACHA20_POLY1305_SHA256 - Unable to set TLS after BSI recommendations
Status: UNCONFIRMED
Priority: --
Created: 2025-02-25 17:23:45+00:00
Resolved: 2025-02-25 18:12:11+00:00

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36 Edg/133.0.0.0

Steps to reproduce:

1. Created a policies.json file with the following contents:
```
{
    "policies":  { 
		"DisabledCiphers":  { 
			"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA":  true,
			"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA":  true,
			"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA":  true,
			"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA":  true,
			"TLS_RSA_WITH_AES_128_GCM_SHA256":  true,
			"TLS_RSA_WITH_AES_256_GCM_SHA384":  true,
			"TLS_RSA_WITH_AES_128_CBC_SHA":  true,
			"TLS_RSA_WITH_AES_256_CBC_SHA":  true,
			"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256":  true,
			"TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256":  true,
			"TLS_CHACHA20_POLY1305_SHA256": true
        },
		"SSLVersionMin":  "tls1.2"
	}
}
 ```
2. Subsequently, placed this file within the installation directory: C:\Program Files\Mozilla Firefox\distribution\policies.json
3. restarted the browser and opened the following website (which tests SSL/TLS Capabilities of the browser): https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html


Actual results:

The Test-Website shows under ```Protocol Features``` > ```Cipher Suites (in order of preference)``` that the following cipher is still usable:
TLS_CHACHA20_POLY1305_SHA256 (0x1303)   Forward Secrecy


Expected results:

TLS_CHACHA20_POLY1305_SHA256 should not be offered by Firefox anymore, since it's in the list of DisabledCiphers

This is a problem because the German BSI (Federal Office for Information Security) doesn't list the Cipher under its Technical Guideline for Cryptographic procedures as an recommended cipher:
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=7

Therefore it is impossible to configure Firefox fully after BSI recommendations.

The BSI justifies why it doesn't recommend the cipher and why disabling the cipher  is not a violation of the TLS1.3 standard here (it is in German language, I can translate it if needed): https://fragdenstaat.de/anfrage/nicht-empfehlung-von-cipher-suite-tls-chacha20-poly1305-sha256-fuer-tls1-3-in-tr-02102-2/
The short version is that the cipher is not nist-standardized and is only an optional part of the standard.
Bug: XFA/js is failing without any error
Status: NEW
Priority: --
Created: 2025-02-25 17:32:13+00:00
Resolved: 2025-02-25 17:32:13+00:00

Attach (recommended) or Link to PDF file here:
https://armement.defense.gouv.fr/sites/default/files/2022-05/NIS_4.0-Avril2022.pdf
as attachment.

Steps to reproduce the problem:
1. In the "Lieu de naissance." section, we can't select the country (and in other pull down menu)

What is the expected behavior? (add screenshot)

In a perfect world, we should support this kind of PDF.
However, until it is the case, we should at least show a message that we don't support this kind of file.
Bug: Remove excess comment in content-analysis.svg
Status: NEW
Priority: P3
Created: 2025-02-25 19:40:14+00:00
Resolved: 2025-02-25 19:40:14+00:00

[content-analysis.svg](https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/content-analysis.svg) has an extraneous comment `<!--stroke="#5B5B66" -->` - it should just be removed.
Bug: Update settingsTemplate to get hostname for supported domains rather than just product pages
Status: NEW
Priority: --
Created: 2025-02-25 19:55:55+00:00
Resolved: 2025-02-26 15:25:31+00:00

Currently, `settingsTemplate` derives `hostname` from `this.getHostnameFromProductUrl()`, which returns null on a non-product page, even if the domain is supported.
https://searchfox.org/mozilla-central/source/browser/components/shopping/content/shopping-container.mjs#594
https://searchfox.org/mozilla-central/source/browser/components/shopping/content/shopping-container.mjs#271

Because of this, the descriptions for auto-open and auto-close settings in Review Checker include the three sites language (Amazon, Best Buy, and Walmart) instead of the single site language intended for amazon.de and amazon.fr when on the domain but not on a product page.
https://searchfox.org/mozilla-central/source/browser/components/shopping/content/settings.mjs#128
Bug: Persisted Search revert button is hard to see with certain themes installed
Status: RESOLVED
Priority: P2
Resolution: FIXED
Created: 2025-02-25 21:55:29+00:00
Resolved: 2025-03-05 20:44:07+00:00

Steps to reproduce:
1) Navigate to https://addons.mozilla.org/firefox/addon/grenen-2-seas-dark-mod/
2) Install the theme
3) Search for something in the address bar
4) Observe the Persisted Search revert button in the address bar

Actual results:
Persisted Search revert button has poor contrast

Expected results:
Persisted Search revert button has good contrast
Bug: Content analysis agent timeout/deny-url/etc should always show response
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-02-25 22:18:56+00:00
Resolved: 2025-02-27 22:01:39+00:00

When timing out, we issue the default response, which may be to block.  The response for items on the deny-url list is always to block.  If `browser.contentanalysis.show_blocked_result` is false then these things will not show a blocked dialog, which means there is no indication of the response, which is wrong.  We should always show a dialog in these cases, regardless of the pref value.  We can add a boolean to indicate `isAgentResponse` [to the response class](https://searchfox.org/mozilla-central/rev/f256e50e068136275c1a2aff827aeddc92a75e07/toolkit/components/contentanalysis/nsIContentAnalysis.idl#50), set it for agent responses [here](https://searchfox.org/mozilla-central/rev/f256e50e068136275c1a2aff827aeddc92a75e07/toolkit/components/contentanalysis/ContentAnalysis.cpp#849), relay that value to `_showCAResult` [here](https://searchfox.org/mozilla-central/rev/f256e50e068136275c1a2aff827aeddc92a75e07/browser/components/contentanalysis/content/ContentAnalysis.sys.mjs#368), and add it to the conditional [here](https://searchfox.org/mozilla-central/rev/f256e50e068136275c1a2aff827aeddc92a75e07/browser/components/contentanalysis/content/ContentAnalysis.sys.mjs#738).
Bug: object element no longer renders PDFs, depends on PDF-download preference
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-25 22:35:48+00:00
Resolved: 2025-02-25 22:50:45+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:135.0) Gecko/20100101 Firefox/135.0

Steps to reproduce:

Select preference for PDF downloads to "Always Ask". Then open a page that includes <object type="application/pdf" data="url-of-pdf">. For example, this page https://templates.getgrist.com/mNp9G2bZ1uaE/Wedding-Planner/p/20#a1.s123.r36.c24, if you double-click on the selected cell  ("Docs" in "VENDORS Card" widget).


Actual results:

Shows fallback text "Preview not available".


Expected results:

It should show a PDF preview in Firefox's built-in PDF viewer. Currently this DOES happen when preference for PDF downloads is set to "Open in Firefox". But this preference applies to links, of course, and never did, nor should, apply to tags of the form <object type="application/pdf" data="some-url">. This changed in the last few weeks.
Bug: Review Checker sidebar close button no longer works
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-26 08:51:03+00:00
Resolved: 2025-03-05 19:26:34+00:00

STR:
1. Set `sidebar.revamp = true` and `browser.shopping.experience2023.integratedSidebar = true`.
2. Enable the "Review Checker" sidebar and open it.
3. Click the close button inside the sidebar.

Expected:
Sidebar closes.

Actual:
Nothing happens.


Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9d99276691fadfa3e296b120bba92cbb5b54c64f&tochange=b102183efb05db57ec69f0dae084718293a3b90d

Regressed by Bug 1921481.
Bug: Text color contrast ineligible when using darker wallpapers
Status: RESOLVED
Priority: --
Resolution: FIXED
Created: 2025-02-26 09:19:44+00:00
Resolved: 2025-03-05 15:07:03+00:00

After this bug got merged (https://bugzilla.mozilla.org/show_bug.cgi?id=1940311), we started getting some a11y issues in regards to some color contrast. Notably when the user has these prerequisites:
- Using a light theme
- Choosing a dark wallpaper from either the Abstract or Photography category

Seems like the issue may be arising from the removal of  `lightWallpaper` and `darkWallpaper` variables in Base.jsx, as those variables are used to toggle color contrast changes in CSS.

**Expected results:**
Font colors in newtab page should be white on dark background 

**Actual results**
Font colors are black on dark background
Bug: Not all windows returned after closing
Status: RESOLVED
Priority: --
Resolution: DUPLICATE
Created: 2025-02-26 09:40:48+00:00
Resolved: 2025-03-03 16:39:19+00:00

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

Steps to reproduce:

Normally Firefox is closed automatically when I shut down the PC.
I needed to close it now for the LibreOffice installation and did so by clicking "close all windows" in the taskbar.
I will NEVER do that again and rather restart my PC after the installation of the third party software.


Actual results:

Of the 11 open windows that were normally returned every time Firefox is started (I clicked that in the settings) 7 were gone, each with multiple tabs in it. Only the last 4 windows were reopened.


Expected results:

I expected ALL windows to come back. 
That always happens when I close Firefox by killing it in the task bar or by having the OS kill it when shutting down.
But shutting it down in the "normal" way offered by the program itself in the task bar apparently has serious problems.
I am hardly doing that so I cannot say if it is a permanent problem but it sucks big time. Keeping tabs of maybe 60 or more open tabs manually is impossible but losing them is the pits.
Bug: Selected sidebar button has hovered appearance that makes it look unselected
Status: NEW
Priority: P3
Created: 2025-02-26 11:08:34+00:00
Resolved: 2025-02-27 17:38:35+00:00

STR:
1. Select the history sidebar.
2. Hover the mouse cursor over the history sidebar button.

Expected:
Selected button color does not change on hover, like with active tab and sidebar toggle in the toolbar.

Actual:
Selected button has same hovered appearance as unselected button.

Bug 1916230 made this more noticeable as it increased the difference between the selected and hovered color.
Bug: selectionStart and selectionEnd are not updatet when the input field is of type="email"
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2025-02-26 11:33:31+00:00
Resolved: 2025-02-26 14:45:48+00:00

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

Steps to reproduce:

    $(document).on('input',".checkadress", function() {
        var $input = $(this);
        var inputElem = this;
        if(typeof emailTimer!=='undefined') clearTimeout(emailTimer); // Vorherigen Timer abbrechen
        emailTimer = setTimeout(function() {
            var email = $input.val();
            console.log(email)
            // Ein einfacher Regex für eine syntaktisch korrekte E-Mail-Adresse
            var emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
            console.log(emailRegex.test(email))
            console.log('start:',inputElem.selectionStart, 'Length:', email.length, 'SelEnd:', inputElem.selectionEnd)
            if (emailRegex.test(email) &&
                inputElem.selectionStart === email.length &&
                inputElem.selectionEnd === email.length) {
                $input.trigger('change');
            }
            }, 1000); // 1 Sekunde Verzögerung
    });


Actual results:

start: null Length: 2 SelEnd: null


Expected results:

start: 2 Length:2