Open Bug 969370 Opened 10 years ago Updated 2 years ago

UITour: Resizing the web page so that the focused button disappears will move the highlight on the top left corner of the window

Categories

(Toolkit :: UI Widgets, defect)

29 Branch
defect

Tracking

()

People

(Reporter: VarCat, Unassigned)

References

Details

(Whiteboard: [Australis:P4-])

Environment:
FF 29.0a2 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Build id:
20140206004003


STR:

1. Start the First Run Tour from https://www.mozilla.org/en-US/firefox/29.0a2/whatsnew/.
2. Go to step 4 of the tour so that bookmark button from toolbar is highlighted
3. Resize the window so that the bookmark button disappears.

Expected:
The highlight disappears also.

Actual:
The highlight is moved to the top left corner of the page.
Blocks: fx-UITour
Neil, can we fix this in the popup code as this is the fourth instance of this issue in UITour alone (bug 949659, bug 967391 and http://hg.mozilla.org/mozilla-central/diff/c1c72268dba6/browser/modules/UITour.jsm are the others).

My proposed fix that will help other consumers too:

If a popup (maybe just panel) is opened with an anchor specified, the panel should hide when the target becomes hidden (e.g. visibility != "visible" or display == "none"). Currently it appears at the top-left of the window.
Component: General → XUL Widgets
Flags: needinfo?(enndeakin)
OS: Windows 7 → All
Product: Firefox → Toolkit
Hardware: x86_64 → All
Summary: First Run Tour: Resizing the web page so that the focused button disappears will move the highlight on the top left corner of the page. → UITour: Resizing the web page so that the focused button disappears will move the highlight on the top left corner of the window
Whiteboard: [Australis:P4]
That's quite hard to do. A general notification that something is hidden is useful and needed for proper focus behaviour as well (bug 570835), but not something I'd be able to implement myself. I might be able to investigate the specific case where the highlight anchor was in another popup and it closed.
Flags: needinfo?(enndeakin)
Can't we at least check the visibility of the anchor inside of nsMenuPopupFrame::SetPopupPosition[1]? This will help for many cases. I don't know enough layout code to know how to do this properly.

[1] https://mxr.mozilla.org/mozilla-central/source/layout/xul/nsMenuPopupFrame.cpp?rev=f6d37fdcc976&mark=1153#1130
Flags: needinfo?(enndeakin)
Whiteboard: [Australis:P4] → [Australis:P4-]
(In reply to Catalin Varga [QA][:VarCat] from comment #0)
> Environment:
> FF 29.0a2 
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
> Firefox/29.0
> Build id:
> 20140206004003
> 
> 
> STR:
> 
> 1. Start the First Run Tour from
> https://www.mozilla.org/en-US/firefox/29.0a2/whatsnew/.
> 2. Go to step 4 of the tour so that bookmark button from toolbar is
> highlighted
> 3. Resize the window so that the bookmark button disappears.
> 
> Expected:
> The highlight disappears also.
> 
> Actual:
> The highlight is moved to the top left corner of the page.

On the latest Beta 29 feature testing we observed that after the highlight is moved to the top left corner of the page if a new tab is opened the highlight shrinks.
Depends on: 1109868
(In reply to Matthew N. [:MattN] (behind on reviews) from comment #3)
> Can't we at least check the visibility of the anchor inside of
> nsMenuPopupFrame::SetPopupPosition[1]? This will help for many cases. I
> don't know enough layout code to know how to do this properly.
> 

Possibly, although it wouldn't work unless a relayout of the popup happens to occur. There are also cases where the anchor isn't visible where you do want the popup to appear anyway.
Flags: needinfo?(enndeakin)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.