cookie lost & no history & shortcut -- bug bug bug
dont know since when edge started to delete ALL LOGIN COOKIE after update. i ve been seeing this for a couple of versions.so after update you will need to login every site that you always visit. and after this newest update edge no longer records your view history. no related history settings are set , since its an auto update. another issue that ppl been discussing , since a version edge canceled the function to setup shortcuts. this is very inconvenient, for almost all software with save functions today will use shift+ctrl+s as a SAVE shortcut, while edge eager to break this habit...(while this s+c+s is still a microsoft invention, sarcastically）.so if no longer look highly on this button you can just delete the funcion. anyway i can move to chrome while edge being still a chrome core, why do i bother all these bugs that other equivalent dont have, when im still a chrome use in the end.
Critical Chat Bugs Remain Unfixed
Version 25094.310.3616.953 was just released and your still have EXTREMELY SERIOUS bugs that are still not fixed. This is disgraceful. Chat Bugs: Bug that makes Teams Chat Worthless: If you set Settings, General, "Open Application in Background" two things happen: First, When restarting Windows the tray icon does not appear. Second (makes Teams Worthless): If you receive a chat message, there is NO notification that it arrived. There is no tray icon and even if you pin Teams to the taskbar, that also does NOT show a notification of a missed chat message. This is makes teams WORTHLESS for chats. More Chat Bugs: Bug 1: Read Receipts do NOT work if you have Teams installed on more than one computer. This is a serous bug that never happened with Skype. Bug 2: The Tray icon does NOT show unread chats. This is a serous bug that never happened with Skype. Note: If your Right click on Teams and select "Pin To Taskbar", that icon will work (but not the tray icon). This assumes you do NOT select ""Open Application in Background"! Bug 3: When set to start up in background, the tray icon does not appear. Bug 4: Right clicking the tray icon causes Teams to crash and the tray icon to close. Bug 5: Teams status is unreliable and frequently shows "unknown". See Screenshot. Get your Act Together. The new Teams app is widely perceived as a buggy festering pile of crap by a significant portion of its user base, particularly among IT professionals tasked with supporting it. While a minority report improvements, the prevailing sentiment is negative, driven by technical problems, forced migration, and inadequate support responses. Many organizations are now seeking alternatives due to the ongoing issues.Introducing the new Microsoft Teams chat and channels experience
Our customers are our greatest source of inspiration, and over the years we have evolved Teams with the goal of helping them achieve more. Today we are taking the next big step in our journey with a new chat and channels experience designed to help you collaborate more efficiently and effectively in the hybrid AI-infused workplace. It is simple by default, enabling everyone to stay on top of what matters, and powerful on-demand, allowing you to organize information and communicate your way.
--js-flags=--noexpose_wasm launch flag causes STATUS_BREAKPOINT
Version 135.0.3179.73 (Official build) (64-bit), Windows 11 Education, also occurs on Windows 10 Education and Windows 10 Pro, been testing this since probably version 129 of Edge. --js-flags=--noexpose_wasm as a launch flag causes STATUS_BREAKPOINT, this is regardless of default configuration and with or without extensions. WASM can be used to discover privileged information about a machine, and this seems to be working in the past according to some users online, but no longer does now. Please can someone advise?
Best practices for safely performing schema changes in Azure Database for MySQL
Azure Database for MySQL - Flexible Server is built on the open-source MySQL database engine, and the service supports MySQL 8.0 and newer versions. This means that users can take advantage of the flexibility and advanced capabilities of MySQL’s latest features while benefitting from a fully managed database service. While newer versions and features can provide a lot of value, the recent issues identified with MySQL versions 8.0+ makes it important to be aware of potential risks that can occur during certain operations, particularly if you are making online schema changes. Issues with data loss and duplicate keys with Online DDL Online Data Definition Language (DDL) operations are a powerful feature in MySQL, enabling schema changes like ALTER TABLE or OPTIMIZE TABLE with minimal impact on table availability. These operations are designed to reduce downtime by allowing concurrent reads and writes during schema modifications, making them an essential tool for managing active databases efficiently. However, a recent post on the Percona blog, Who Ate My MySQL Table Rows? highlights critical risks associated with MySQL 8.0.x versions after 8.0.27 and all versions beyond 8.4.y. Specifically, the open-source INPLACE algorithm, commonly used for online schema changes, can lead to data loss and duplicate key errors under certain conditions. These issues arise from constraints in the INPLACE algorithm, particularly during ALTER TABLE and OPTIMIZE TABLE operations, exposing vulnerabilities that compromise data integrity and system reliability. These risks are called out in the following bug reports: Bug #115511: Data loss during online ALTER operations with concurrent DML Bug #115608: Duplicate key errors caused by online ALTER operations Documented issues related to the INPLACE algorithm (used for online DDL) can cause: Data Loss: Rows may be accidentally deleted or become inaccessible. Duplicate Keys: Indexes can end up with duplicate entries, leading to data consistency issues and potential replication errors. Problems arise when INPLACE operations, such as ALTER TABLE or OPTIMIZE TABLE, run concurrently with: DML operations (INSERT, UPDATE, DELETE): Modifications to table data during the rebuild. A purge activity: Background cleanup operations for old row versions in InnoDB. These scenarios can lead to anomalies resulting from race conditions and incomplete synchronization between concurrent activities. Impact on Azure Database for MySQL - Flexible Server Customers For Azure Database for MySQL Flexible Server customers using MySQL 8.0+ and all versions after 8.4.y, this issue is particularly critical as it affects: Data Integrity: During schema changes such as ALTER TABLE or OPTIMIZE TABLE run using the INPLACE algorithm, data rows may be lost or duplicated if these operations run concurrently with a DML activity (e.g., INSERT, UPDATE, or DELETE) or background purge tasks. This can compromise the accuracy and reliability of the database, potentially leading to incorrect query results or the loss of critical business data. Replication Instability: Duplicate keys or missing rows can interrupt replication processes, which rely on a consistent data stream across the primary and replica servers. These issues can arise when there are concurrent insertions into the table during schema changes, leading to data inconsistencies between the primary and replicas. Such inconsistencies may result in replication lag, errors, or even a complete breakdown of high-availability setups, requiring manual intervention to restore synchronization. Operational Downtime: Resolving these issues often involves manually syncing data or restoring backups. These recovery efforts can be time-consuming and disruptive, leading to extended downtime for applications and potential business impact. Recommendations for safe schema changes on Azure Database for MySQL flexible servers To minimize the risks of data loss and duplicate keys while making schema changes, follow these best practices: Set old_alter_table=ON to Default to COPY Algorithm Enable the server parameter old_alter_table system variable so that ALTER TABLE operations without a specified ALGORITHM default to using the COPY algorithm instead of INPLACE. This reduces the risk for users who do not explicitly specify the ALGORITHM in their commands. Learn more on how configure server parameters in Azure Database for MySQL. Avoid using ALGORITHM=INPLACE Do not explicitly use ALGORITHM=INPLACE for ALTER TABLE commands, as it increases the risk of data loss or duplicate keys. Back up your data before schema changes Always perform a full on-demand backup of your server before executing schema changes. This precaution ensures data recoverability in case of unexpected issues. Learn more on how to take full on-demand backups for your server. Avoid Concurrent DML during schema changes Schedule schema changes like ALTER TABLE and OPTIMIZE TABLE during application maintenance windows when no concurrent writes activities occur. This minimizes race conditions and synchronization conflicts. Use External Tools for Safer Online Schema Changes Consider using external tools like pt-online-schema-change to modify table definitions without blocking concurrent changes. These tools enable you to make schema changes with minimal impact on availability and performance. Learn more about pt-online-schema-change. Disclaimer: The pt-online-schema-change tool is not managed or supported by Microsoft; use it at your discretion. Mitigation plans To address these risks, we’re actively working to integrate the necessary fixes to ensure a more robust and reliable experience for our customers. New Servers Fully Secured by End of February 2025 All new Azure Database for MySQL Flexible Server instances created after 1 st March 2025, will include the latest fixes, ensuring that schema changes are safeguarded against data loss and duplicate key risks. Rollout for Existing Servers For existing servers, we will roll out patches during upcoming maintenance windows by end of Q1 of Calendar Year 2025 We recommend monitoring your Azure portal for scheduled maintenance windows and Release notes for announcements about critical updates and patches. Priority updates available upon request If you require an urgent update outside of the scheduled maintenance windows, you can contact Azure Support. Provide the necessary server details and an appropriate maintenance window, and our team will work with you to prioritize the patching process. Note that priority patching will be available by February 2025. We recommend monitoring Release notes for announcements about critical updates and patches. Conclusion Safely managing schema changes on MySQL servers requires understanding the risks associated with online DDL operations, such as potential data loss and duplicate keys. To help safeguard data integrity and maintain server stability, implement best practices, for example enabling the COPY algorithm, using offline operations if feasible, or scheduling changes during low activity periods. Fixes are expected by the end of February 2025, and new Azure Database for MySQL flexible servers will be fully protected against these bugs. We will apply updates to existing servers during maintenance windows in Q1 2025. Following the recommendations above will help ensure that you can confidently make schema changes while preserving the reliability and performance of your server.Pinning the new (Outlook) Calendar in Teams
Not sure if anyone else has noticed, but the new calendar seems to refuse being pinned to the left navigation. Using version: 24295.612.3262.1872 The good news is I think I found a workaround: switch back to the old calendar Pin it Switch back Worked on my end. I might have been in this predicament because I originally had the new calendar installed as a separate app (from the Teams store). Since updating last night, that app went away but I was now able to view the toggle to switch to the new calendar. Now the only issue is that I can't move the pinned calendar to another position on the navigation. Anyone else having these issues? I've experienced this on two different accounts, on different devices.
