Open Bug 1779396 Opened 2 years ago Updated 2 years ago

svh(and it's logical version) unit should take the keyword search bar, which can be dynamically expanded in the bottom of the page, into consideration

Categories

(Toolkit :: Find Toolbar, defect)

Firefox 101
Desktop
All
defect

Tracking

()

People

(Reporter: zjz, Unassigned)

References

Details

Attachments

(1 file)

Attached file test.html

See the uploaded test.html, it provides a case to prove that the current svh(and its logical version) isn't 100% safe to avoid obscuring page contents.

When the search bar in the bottom is opened or hided, the size and the position of the content of test.html get obscured, which does not comply to what the W3C document suggests.

Edit: obscured => reflowed

You mean in Firefox desktop or mobile? In desktop the search bar changes the height of the viewport.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

You mean in Firefox desktop or mobile? In desktop the search bar changes the height of the viewport.

I mean the desktop version(I set the platform item to Desktop).
Yes, it changes the height of the viewport, so contents streamed in vertical direction could get obscured.

Blocks: 1610815
No longer blocks: 1759675
Summary: svh(and it's logical version) unit should take the keyword search bar, which can be dynamic expanded in the bottom of the page, into consideration → svh(and it's logical version) unit should take the keyword search bar, which can be dynamically expanded in the bottom of the page, into consideration

But content isn't obscured, it's reflowed because the viewport is smaller. What am I missing?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

But content isn't obscured, it's reflowed because the viewport is smaller. What am I missing?

Sorry for the wrong word, it is correct to call it "reflowed".
Whatever, the viewport is changed, so it's an unexpected UX if I am using a "safe" svh, isn't it?

Well, not really. That's been the behavior for ages, vh / vw change with that. So this is mostly a proposal to change the Find UI inside Firefox, more than a bug in the style system.

Component: CSS Parsing and Computation → General
Product: Core → Toolkit

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

Well, not really. That's been the behavior for ages, vh / vw change with that. So this is mostly a proposal to change the Find UI inside Firefox, more than a bug in the style system.

I think you meant Bug 869543 . I'd be glad to see this issue resolved either way, let's remain this issue as open, while tracking Bug 869543, if Bug 869543 is fixed, this bug can be closed.

See Also: → 869543
No longer blocks: 1610815
Depends on: 1610815
Component: General → Find Toolbar

The severity field is not set for this bug.
:enndeakin, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)
Severity: -- → S4
Flags: needinfo?(enndeakin)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: