Bugzilla

I think my reasoning in comments 4-5 suggest that this should perhaps not be [access-s2], and should probably be closed as not-actually-a-bug.

Summarizing: this bug was filed due to an apparent-inconsistency between different types of dropdowns (select honor the full-page-zoom, while others do not); and to the reporter, this looked like an oversight.

But in fact: <select>-dropdowns are special among "browser overlays" in responding to full-page-zoom, because web developers can style their contents, which means there's no guarantee that they honor the users' sizing preferences (as expressed via OS defaults); so we need to make them respond to full-page-zoom to give users a way to counteract individual pages' poor design choices.

In contrast, other dropdowns' contents should always use text that matches the OS defaults and that's the same size as all of our other frontend UI (menus/tab-titles/etc).  The correct way to make all of that UI easier to read is through configuring the operating system's resolution and font preferences (or using other accessibility tools like screen-magnifiers, as-desired), not through one-off full-page-zoom adjustments.

I think my reasoning in comment 4 - comment 5 suggests that this should perhaps not be [access-s2], and should probably be closed as not-actually-a-bug.

Summarizing: this bug was filed due to an apparent-inconsistency between different types of dropdowns (select honor the full-page-zoom, while others do not); and to the reporter, this looked like an oversight.

But in fact: <select>-dropdowns are special among "browser overlays" in responding to full-page-zoom, because web developers can style their contents, which means there's no guarantee that they honor the users' sizing preferences (as expressed via OS defaults); so we need to make them respond to full-page-zoom to give users a way to counteract individual pages' poor design choices.

In contrast, other dropdowns' contents should always use text that matches the OS defaults and that's the same size as all of our other frontend UI (menus/tab-titles/etc).  The correct way to make all of that UI easier to read is through configuring the operating system's resolution and font preferences (or using other accessibility tools like screen-magnifiers, as-desired), not through one-off full-page-zoom adjustments.

I think my reasoning in comment 4 - comment 5 suggests that this should perhaps not be [access-s2], and should probably be closed as not-actually-a-bug.

Summarizing: this bug was filed due to an apparent-inconsistency between different types of dropdowns (`<select>` dropdowns honor the full-page-zoom, while text-`<input>` autocomplete / datalist dropdowns do not); and to the reporter, this looked like an oversight.

But in fact: <select>-dropdowns are special among "browser overlays" in responding to full-page-zoom, because web developers can style their contents, which means there's no guarantee that they honor the users' sizing preferences (as expressed via OS defaults); so we need to make them respond to full-page-zoom to give users a way to counteract individual pages' poor design choices.

In contrast, other dropdowns' contents should always use text that matches the OS defaults and that's the same size as all of our other frontend UI (menus/tab-titles/etc).  The correct way to make all of that UI easier to read is through configuring the operating system's resolution and font preferences (or using other accessibility tools like screen-magnifiers, as-desired), not through one-off full-page-zoom adjustments.

I think my reasoning in comment 4 - comment 5 suggests that this should perhaps not be [access-s2], and should probably be closed as not-actually-a-bug.

Summarizing: this bug was filed due to an apparent-inconsistency between different types of dropdowns (`<select>` dropdowns honor the full-page-zoom, while text-`<input>` autocomplete / datalist dropdowns do not); and to the reporter, this looked like an oversight.

But in fact: <select>-dropdowns are special (maybe unique?) among "browser overlay UI" in responding to full-page-zoom, because web developers can style their contents, which means there's no guarantee that they honor the users' sizing preferences (as expressed via OS defaults); so we need to make them respond to full-page-zoom to give users a way to counteract individual pages' poor design choices.

In contrast, other dropdowns' contents should always use text that matches the OS defaults and that's the same size as all of our other frontend UI (menus/tab-titles/etc).  The correct way to make all of that UI easier to read is through configuring the operating system's resolution and font preferences (or using other accessibility tools like screen-magnifiers, as-desired), not through one-off full-page-zoom adjustments.