Critical Pen Hover & Stray Ink Issue on New Surface Pro 11 for Business with Slim Pen 2
Hello Microsoft Community and Support Staff, I am writing to report a critical and seemingly widespread issue with the pen input on the brand-new Surface Pro for Business, 13-inch (Intel model, often called Surface Pro 11 "Luna Lake"). The Core Problem: Pen Draws Without Touching the Screen When using the Surface Slim Pen 2, the device begins to register ink input while the pen is still hovering a few millimeters above the screen. It does not require any physical contact or pressure. This "hover-inking" makes handwriting completely unusable. As I write, any time I lift the pen to start a new letter or stroke, the pen continues to draw a line as it moves through the air to its next position. This results in messy, connected handwriting with unwanted "tails," completely defeating the purpose of having a premium inking device. This is Not a Defective Unit - It's a Replicable Problem Initially, I thought I had a faulty device. However, to isolate the issue, I have performed extensive testing: I have personally tested this on [3] brand-new Surface Pro 11 (Intel) devices. I have used [4] different Slim Pen 2s. The exact same hover-inking problem occurred on every single combination of device and pen. Furthermore, I have already performed all standard troubleshooting steps, including: Clean OS installation via Surface Recovery Image. Ensuring all Windows, driver, and firmware updates are installed. Running the Surface Diagnostic Toolkit (which reported no errors). However, the same issue continues to occur even after trying these methods. Additionally, it has been reported that the issue also appears on the latest Surface Pro 12-inch model with the Snapdragon X Plus, just like on the Surface Pro 11 that uses the Qualcomm Snapdragon X Elite instead of Intel’s Lunar Lake. (I do not own any Snapdragon devices myself. If you own a Snapdragon device and are experiencing the same issue, please share your feedback.)" Video Evidence: I have recorded a clear video demonstrating the problem. It shows the pen drawing while hovering on the Surface Pro 11 and makes unwanted tails on handwriting letters. Video Link: https://youtube.com/playlist?list=PLG_7BXFA-cL4evqe0RmRz--iFjDC1HVgT&si=EmEypaAqSyRozr67 Questions for Microsoft: Is this a known issue with the new Surface Pro 11 (Intel) model's firmware or drivers? What are the official steps to escalate this issue directly to the Surface engineering team for a fix? This is a major flaw in a flagship product that severely impacts its core functionality. I have submitted a formal bug report through the Feedback Hub, which can be found here: Feedback Hub Link: https://aka.ms/AAxzh27 I urge the Microsoft team to investigate this with high priority and release a firmware or software update to recalibrate the pen's Initial Activation Force (IAF). Thank you for your attention to this serious matter.
MS Edge - Sidebar and copilot not working on Linux Ubuntu v24 LTS
Sidebar not syncing or accepting new app additions (+). Copilot button is dead/inactive. Sidebar settings are well configured. Using the latest version of the Ubuntu OS and MS Edge. Functionality appears to be absent as product was released without full functionality....Lame!
Latest Stable Linux build of Edge crashes when I download something.
When I download something from the internet and When I click save as the browser crashes, using RPM linux build on Fedora and using the latest stable version at the time of writing this discussion version Version 143.0.3650.139 (Official build) (64-bit)
When using touch mode, clicking the "extension" button on the toolbar causes Edge to crash
Version 146.0.3844.0 (Official build) dev (64-bit) When using touch mode, clicking the extensions button on the toolbar causes Edge to freeze for two to three seconds before crashing. Accessing edge://extensions/ displays normal functionality, I can open extension detail pages and configure settings without issue. Reinstalling Edge or uninstalling all extensions resolves the problem. Disabling touch mode restores normal behaviour.
Office v2508 feature update (new vbe7.dll) breaks library compatibility with LTSC VL versions
Since the Jan 2026 updates, some `accde` or `mde` libraries built with the semi-annual enterprise channel (v2508, Build 19127.20484) can no longer be used with the volume-licensed version of Office LTSC (tested with the Jan 2026 release of Office 2024 LTSC VL, v2408, Build 17932.20638). The reason for this seems obvious: The v2508 feature update contains an updated vbe7.dll. Apparently, this change is backwards-compatible (code compiled with the old dll will run with the new dll) but not completely forwards-compatible (code compiled with the new dll might not run with the old dll, even if the new RegExp class is not used). That's a problem for us. We can't just tell our customers to upgrade, because those with an Office 2024 LTSC volume license already use the latest version available to them. Does Microsoft consider this a bug or "by design"? If the latter, what is Microsoft's recommendation for software vendors who want to build software that runs on all currently-supported versions of Access? We currently plan to work around this issue by installing v2502 of the semi-annual enterprise channel on our "build VMs" (32 and 64 bit) and use those to build our software. (Reverting dev machines to an old Office version is not an option for obvious security reasons.) Repro On a PC with v2508 or newer: 1. Create a new mylibrary.accdb with a module with the following code: Public Function GetColorCode() As Long GetColorCode = vbRed End Function 2. File/Save as/Create accde. 3. Copy mylibrary.accde to a PC with v2507 or older (for example, with the current version of Office 2024 LTSC volume license). On a PC with v2507 or older: 4. Create a new database. 5. Create/Module/Tools/References 6. Add a reference to mylibrary.accde 7. Add the following code to the module: Sub Test() Debug.Print GetColorCode() End Sub 8. Debug/Compile Expected result: The database compiles. Actual result: "Compile error: Can't find project or library". The "references" window opens automatically and highlights "mylibrary". Notes We are not library developers, but we are still impacted by this issue, since the software we ship consists of a (modifiable) startup mdb referencing an (unmodifiable) mde containing the business logic. If you want to try to reproduce this issue but don't have a volume license of Office 2024 LTSC lying around (we certainly don't), you can install a trial version with the Office Deployment Tool and the following configuration file: <Configuration> <Add OfficeClientEdition="64" Channel="PerpetualVL2024"> <Product ID="ProPlus2024Volume"> <Language ID="en-us" /> </Product> </Add> </Configuration>The return of the performance leak - this time with subreports
Anyone remember the v2405 bug that caused loading and closing forms to become slower over time? We found something similar in the current release (tested with semi-annual 2508 (19127.20484)), just with sub reports instead of forms. Here are the repro instructions: Repro instructions Table 1. Create a "numbers" table with a PK field "nr" (Long Integer). 2. Fill it with the numbers from 1 to 100: Dim i For i = 1 To 100 CurrentDb.Execute "INSERT INTO numbers (nr) VALUES (" & i & ")" Next i Sub report 3. Create a new empty report in design view, using the "numbers" table as the record source. 4. In the detail section, add two text boxes "Text1" and "Text2" next to each other, both with the "nr" field as their control source. 5. Reduce the size of the detail section to one "row", containing just the two text boxes. Remove the page header/footer. 6. Add an Format event handler to the detail section with the following content: Me.Text2.Visible = False 7. Save the report as "sub". Main report 8. Create another report "main", which contains nothing but the "sub" report as a subreport in its detail section. Set the record source of "main" to "SELECT * FROM numbers WHERE nr <= 10" Reproduce problem 9. Create the following method in a module: Sub report_loop() Dim i As Long Dim start_time As Single Dim report_name As String Dim path As String report_name = "main" For i = 1 To 40 path = Environ("Temp") & "\testreport.pdf" start_time = Timer DoCmd.OpenReport report_name, acViewPreview DoCmd.OutputTo acOutputReport, report_name, acFormatPDF, path DoCmd.Close acReport, report_name Debug.Print Timer - start_time Next End Sub 10. Run report_loop. Observe that each report export gets slower and slower. Analysis Compare the first and last number in the immediate window: on my machine it's 0.4s for the first report and 2.3s for the last. Note that if you run report_loop again, it will start slow! In other words, each report export causes MS Access to "leak performance" that is only regained after restarting Access. We were able to reproduce this issue with Microsoft 365 semi-annual channel, Version 2508 (19127.20484). I'll do more tests tomorrow and try different older versions to find out when this bug was introduced. Workarounds If you move the visibility code from the Format event to the Print event, the problem still occurs, but slower (0.4s -> 0.72s instead of 0.4s -> 2.3s). The workaround that worked for us was to use =IIf(...) in the control source instead of modifying the visibility. Obviously, that only works for text boxes, not for lines or other controls.
[Wayland] PWAs no longer appear as separate app windows — all group under main Edge icon
Hi, Since around 2025-09-07 to 2025-09-10, I’ve noticed that on GNOME (Wayland) all installed PWAs (even across different profiles) now appear grouped under the main Edge browser icon in the GNOME Shell dash/taskbar. Previously, each PWA would open in its own window group with its own icon. This is still the behavior in Chromium/Brave/Chrome, and can be restored there by editing the PWA’s .desktop file to set: StartupWMClass=<same value as Icon> However, Edge now seems to ignore StartupWMClass completely on Wayland, breaking workspace separation and making task switching hard. Environment: Ubuntu 25.04 GNOME 48.0 / Mutter (Wayland) Kernel 6.14.0-29 Intel Iris Xe GPU Edge (latest stable, observed post 2025-09-13) Repro steps: Install any PWA (e.g. Outlook, Teams, Spotify) from Edge Launch it (from any profile) Observe that it appears grouped under the main Edge browser icon Expected: PWA shows under its own icon and window group like in Chromium-based browsers Actual: All PWAs are bundled into the main Edge window group Editing StartupWMClass in the .desktop file no longer helps This regression makes PWAs much harder to manage on Wayland. Please route to the Linux/Wayland team if possible. Thanks!
