Where did you install Firefox from? Help Mozilla uncover 3rd party websites that offer problematic Firefox installation by taking part in our campaign. There will be swag, and you'll be featured in our blog if you manage to report at least 10 valid reports!

Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

Learn More

Scary message delete behavior when content display blocked

  • 1 trả lời
  • 1 gặp vấn đề này
  • 3 lượt xem
  • Trả lời mới nhất được viết bởi wevdap

more options

In Thunderbird 1153.1 (MacOS), it appears that the "Delete" button next to the header information on a message whose content display is blocked per privacy settings is applied not to that individual message but rather to the folder containing it. There's (fortunately!!) a confirmation dialog warning that that entire folder would be deleted unrecoverably, but it seems non-intuitive and dangerous that the button's scope should change depending on the content display status. When the content is displayable, the button applies only to the individual message, as I'd expect.

In Thunderbird 1153.1 (MacOS), it appears that the "Delete" button next to the header information on a message whose content display is blocked per privacy settings is applied not to that individual message but rather to the folder containing it. There's (fortunately!!) a confirmation dialog warning that that entire folder would be deleted unrecoverably, but it seems non-intuitive and dangerous that the button's scope should change depending on the content display status. When the content is displayable, the button applies only to the individual message, as I'd expect.

Giải pháp được chọn

115.4.1 may have fixed this - on a quick check following an update, I'm not seeing this behavior.

Đọc câu trả lời này trong ngữ cảnh 👍 0

Tất cả các câu trả lời (1)

more options

Giải pháp được chọn

115.4.1 may have fixed this - on a quick check following an update, I'm not seeing this behavior.