[Word Addin] Input Fields with Certain IDs ("test", "subject") Lose Focus in Word Version 2502

[KristianLonergan]

Input Fields with Certain IDs ("test", "subject") Lose Focus in Word Version 2502

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: PC Desktop
• Host [Excel, Word, PowerPoint, etc.]: Word
• Office version number: 2502 (issue does not occur in 2501)
• Operating System: Windows 11
• Browser (if using Office on the web): Side loading code into word addin side panel

Expected behavior

All input fields should receive focus when clicked, allowing the user to enter text, regardless of the id or name values used.

Current behavior

Input fields that use certain keywords such as "test" or "subject" for their id/name lose focus immediately when clicked, preventing any user input. In contrast, an input with a hyphenated name/id like "first-name" works as expected.

Steps to reproduce

1. Create an Office Add-in for Word with a task pane containing HTML inputs.

2. Insert the following HTML snippet into your add-in:

   <label htmlFor='test'>Test</label>
   <input type='text' name='test' id='test' placeholder='Enter test' />
   
   <label htmlFor='subject'>Subject</label>
   <input
    type='text'
    name='subject'
    id='subject'
    placeholder='Enter subject'
   />
   
   <label htmlFor='first-name'>Firstname</label>
   <input
    type='text'
    name='first-name'
    id='first-name'
    placeholder='Enter firstname'
   />

3. Load the add-in in Word.

4. Click on the inputs with id/name values "test" and "subject". Notice that they lose focus immediately. The input with id/name "first-name" behaves correctly.

Provide additional details

1. The issue is specific to Word version 2502; the same code works as expected in Word version 2501.
2. Changing the input's id/name from a common keyword (e.g., "test", "subject") to a hyphenated identifier (e.g., "first-name") resolves the issue.
3. This suggests that Word may be treating these common identifiers as reserved keywords or binding them to internal logic, causing the inputs to lose focus immediately.

[GardiantAndyTonthat]

Just as an update, this also occurs when the name field contains the word "email" in it. We need to change it to something else completely different in order for the focus to work.

This also applies to Outlook as well.

[majid701]

I am facing the same issue in Excel, here the focus is jumping to a cell in the spreadsheet instead. It happens for certain input fields including the ones with normal / hyphenated name id's

[KristianLonergan]

@GardiantAndyTonthat @majid701 A temporary workaround for this issue seems to be changing inputs to be a textarea so looks like a issue specific to inputs of type text

[mtruyens]

My customers are also suffering from this problem. A quick fix would be very, very much appreciated!

It does not seem to happen in OfficeJS on Mac.

[broniec]

I am observing the same issue as well with an Outlook Add-In. I will look at switching inputs to textareas, but also interested if there are other alternatives.

[graysenpack]

We're seeing the same thing with our Windows users. Seems to be text fields related to "name" or similar labels.

This seems to be happening across Office products as well: https://github.com/OfficeDev/office-js/issues/5476

[ufoot]

Looks like we're hit by this too, our field is email as mentioned in this previous report. Also as others mentioned, works on Mac, broken on Win11. Word Online through Office365 is fine too.

[greghaik]

I confirm, encountered this as well. That's a critical bug for us, I hope you guys can sort this out soon ! 🙏

[shermaro91]

My clients are also facing the same issue and they are very frustrated. It will be very helpful if this issue fix asap as its impacting our business.

[PauliusMilmantas]

This is a critical issue for us and our clients. Get your **** together, Microsoft.

[guoms1]

Hi, @KristianLonergan, @GardiantAndyTonthat, @majid701, @mtruyens, @broniec , @graysenpack, @ufoot , @greghaik, @shermaro91, @PauliusMilmantas

I'm sorry to hear you're experiencing this issue. I wasn't able to reproduce the problem on Word Desktop build 2503, so it appears that the issue may have been resolved in this build. To help clarify, I recorded a video that shows both the HTML code I used and a live demo of the Word add-in's Taskpane. I hope you find this helpful.

Please let me know if you have any further questions or need additional assistance.

Best regards,

https://github.com/user-attachments/assets/25e16722-772e-492b-8150-ba178d5f95b8

[abed-daloopa]

@guoms1 For our team, this impacts a significant subset of Windows Excel desktop users, but not all. Even among teammates with the same Excel version and OS, only some are affected.

[mtruyens]

@guoms1 — do I understand correctly that you think the issue is limited to just one version of Word/Excel/Outlook? Because I can show you the videos of customers where a certain version is rolled out (and it may take weeks before a new version would be rolled out) that are really suffering from this situation.

Alternatively, is there any way this can be temporarily resolved without having to rename all the input-boxes?

[KristianLonergan]

@guoms1 When will build 5203 be available ?

[guoms1]

Hi, @abed-daloopa

Your feedback is very important. It means that we cannot conclude that the bug is resolved on build 2503 just because it could not be reproduced by me. We understand the serious impact this issue is having, and we're actively investigating it. If we find any workarounds or have further progress, we'll let everyone know as soon as possible.

Best,

[majid701]

@guoms1 Sorry for the late reply here guys but the issue here is not connected to a specific version of MS Product, this is related to the Edge WebView2 Runtime which is used to render all add-in applications (reference issue: https://github.com/MicrosoftEdge/WebView2Feedback/issues/5144)

Add-in ref: https://github.com/MicrosoftEdge/WebView2Feedback/issues/5144#issuecomment-2715568115

Seems like everyone on the version 134.0 are affected by this problem that explains why @mtruyens, @abed-daloopa don't see a common pattern among users. The Webview version in Microsoft seems to be rolled out in a mysterious way (maybe through Windows updates)

However the last comment in the above linked issue says that the problem is patched and a new version will be rolled out soon, when will that happen we don't know that yet.

Workaround: For those looking for a workaround there are 3 possibilities:

• Right click and pasting in the input field works
• Right click then press ESC and the field should get focus and user is able to type
• Tab key to move through fields works as well

Hope this helps

[graysenpack]

Great insight @majid701!

I know for us the third option (tabbing into the field) would work with a small number of users, but didn't in most cases. I haven't tried the right-click & paste/esc but will update if I can find any success with this.

The only success we've had was removing any tags or label related to name, email, or other autofill compatible content. If I manually changed the name of our login field from "Email" to "Something" through Inspect (changing nothing else), we could focus into the field and type like normal. It would go back to the broken state if I changed it back to "Email" again.

[broniec]

@majid701

For us, tabbing would allow the input to be selected, but the field could still lose focus when the user was typing. I ended up renaming all of the input fields and confirmed that this fixed the issue.

[shermaro91]

Hi @broniec what exactly you did? can you share here?

[mtruyens]

Hi, @abed-daloopa

Your feedback is very important. It means that we cannot conclude that the bug is resolved on build 2503 just because it could not be reproduced by me. We understand the serious impact this issue is having, and we're actively investigating it. If we find any workarounds or have further progress, we'll let everyone know as soon as possible.

Best,

@guoms1 Perhaps interesting to have a look a the attached video of one of my users (Word is set to German, but that shouldn't be relevant here). You can see that every time the user tries to focus on one of the email-fields in the addin, the focus gets thrown back to MS Word.

https://github.com/user-attachments/assets/32633197-69a0-4981-b463-c57bcbc0a625

The version of Word used is 2412, build 18324.20240

[Rens-Braspenning]

Hi @broniec what exactly you did? can you share here?

Just fixed it on our Office Addin, renamed the name attribute value of the input element. Instant fix.

[broniec]

Hi @broniec what exactly you did? can you share here?

Hi @broniec what exactly you did? can you share here?

Just fixed it on our Office Addin, renamed the name attribute value of the input element. Instant fix.

Yes, our add-in is developed in-house, so I changed the name & id attributes of each element to a different name. For example, name="email" could be name="arbitrary-name-1234" and same for id attribute. Any references to those names would need to be refactored as well. I would love to return to the original names once the issue is fixed, since this is clearly a bug, but this works for an immediate solution.

[mtruyens]

Hi @broniec what exactly you did? can you share here?

Hi @broniec what exactly you did? can you share here?

Just fixed it on our Office Addin, renamed the name attribute value of the input element. Instant fix.

Yes, our add-in is developed in-house, so I changed the name & id attributes of each element to a different name. For example, name="email" could be name="arbitrary-name-1234" and same for id attribute. Any references to those names would need to be refactored as well. I would love to return to the original names once the issue is fixed, since this is clearly a bug, but this works for an immediate solution.

I can confirm; exactly the same approach here on our side (but the problem being the HTML placeholder attribute — similar fix by simply renaming it temporarily).

[majid701]

This is not patched in the latest version of Edge Webview2 Runtime 134.0.3124.68 and working as expected

[trigurl]

Hello folks please refer to https://github.com/MicrosoftEdge/WebView2Feedback/issues/5144

1) Try updating to yesterday's version of 134.0.3124.68 WebView2 Runtime. https://developer.microsoft.com/en-us/microsoft-edge/webview2/?form=MA13LH

2) Try again after shutting down all WV2 instances by "tskill msedgewebview2*" or rebooting your machine.

Can you see if this works?

[guoms1]

Close this issue as patching with Edge Webview2 Runtime 134.0.3124.68 fixed this issue.