The same buttons are also in the main UI and they do the same thing.

...so please remove either one when showing about:addons.

Either bug 571970 or this one needs to be fixed before release I think.

Intended, chrome will go away. INVALID

(In reply to comment #3) > Intended, chrome will go away. > INVALID Except that hasn't been done yet and is not a blocker so may not happen before Firefox 4.

In-Content UI will happen. Not in intended range, but it will. Confirmed be Stephen.

What's the reason for blocking? Don't tell me even In-Conent UI won't make it at all...

(In reply to comment #6) > What's the reason for blocking? Don't tell me even In-Conent UI won't make it > at all... Unless we fix bug 571970 and hide the main UI navigation buttons (and we haven't found a nice way to do that for all cases yet, and the bug isn't marked as blocking) then we have to do something here, so it should block the release.

This removes the buttons and fixes the test, also re-enables it with a longer timeout which I think is all that is necessary. I'm unsure whether to remove the actual strings in case we decide to bring this back again.

There's likely some theme code that should be removed along with the buttons.

A bit OT, but since In-Content UI is scratched for 4.0, how do you intend to polish AOM? Because in current state it looks anyhow except good.

Indeed, this has the theme changes included.

I've been thinking. Couldn't you make pseudo-In-Content UI by extending toolbar background into AOM?

(In reply to comment #11) > Created attachment 477960 [details] [diff] [review] > patch rev 2 > > Indeed, this has the theme changes included. navigation.png should be removed too, from jar.mn at least.

Indeed, hopefully this one is good now

Comment on attachment 478285 [details] [diff] [review] patch rev 3 Given that the only time these would be added back is post-4.0 (and even then, only maybe), the strings should just be removed. Tracking down unused and forgotten strings is a real pain :(

Can I see screenshot with applied patch, please?

Fixed: http://hg.mozilla.org/mozilla-central/rev/4fa6d886a06e

This checkin made the default branch and the b7 relbranch diverge in strings, which is something that can cause problems for locales - can we either have that landed for b7 or the string change reverted for the moment?

We've reverted the string change in http://hg.mozilla.org/mozilla-central/rev/41aded65fb6c. I'll talk with people tomorrow to see if it would be better to take it all on the relbranch too or to wait till after b7 has shipped to remove the strings from trunk.

Backed this out as apparently now bug 571970 is going to happen for just tabs-on-top so we need these here for that case. Need a new patch to hide buttons when the navigation bar is visible.

This hides the navigation buttons based on context. If the manager is displayed in its own window or it is displayed in a frame where the top-level window doesn't have a visible element with ID back-btn then the buttons are visible, otherwise they are hidden. This also implements full history support for the windowed case. I've also fixed bug 599891 here to have full testing of the windowed case. Any tests that use the UI are copied to a second testing directory where the head.js detects that window testing is wanted and enforces it. I haven't bothered with any magic to stop double-running all the tests in the case that the app they are running in doesn't support in-content. As far as I know only Seamonkey and Firefox run these tests and they both do. I'll add further tests for ensuring the buttons appear/disappear when the toolbar/buttons appear/disappear in bug 571970, it is a waste of time to do that before then.

Comment on attachment 485079 [details] [diff] [review] new approach rev 1 >+ // Check whether to show the navigation buttons >+ var docshellItem = window.QueryInterface(Ci.nsIInterfaceRequestor) >+ .getInterface(Ci.nsIWebNavigation) >+ .QueryInterface(Ci.nsIDocShellTreeItem); >+ >+ // If there is no outer frame then leave the buttons visible >+ if (docshellItem.rootTreeItem == docshellItem) >+ return; >+ >+ var outerWin = docshellItem.rootTreeItem.QueryInterface(Ci.nsIInterfaceRequestor) >+ .getInterface(Ci.nsIDOMWindow); >+ var outerDoc = outerWin.document; >+ var node = outerDoc.getElementById("back-button"); >+ // If the outer frame has no back-button then leave the buttons visible >+ if (!node) >+ return; >+ >+ // If the back-button or any of its parents are hidden then leave the buttons >+ // visible >+ while (node != outerDoc) { >+ var style = outerWin.getComputedStyle(node, ""); >+ if (style.display == "none") >+ return; >+ if (style.visibility != "visible") >+ return; >+ node = node.parentNode; >+ } >+ >+ // Otherwise there is an outer frame with a visible back-button so hide the >+ // navigation buttons >+ document.getElementById("back-btn").hidden = true; >+ document.getElementById("forward-btn").hidden = true; > } Think this has the potential to flash the buttons - better to default to hidden, have have the code show them (I know this will probably make the code less nice). If the browser back/forward buttons are shown/hidden while the addons manager is already loaded in a tab, its buttons won't update their visibility accordingly - but I don't think that's a big deal (and its quite an edge case). Also can't think of any way to reasonably detect that anyway.

Split it out into a separate function to make that work ok, also made the buttons default to disabled to avoid that flickering

Comment on attachment 485331 [details] [diff] [review] New approach rev 2 >+ if (shouldShowNavButtons()) { >+ document.getElementById("back-btn").hidden = false; >+ document.getElementById("forward-btn").hidden = false; >+ } Think it makes sense to move this into gHeader.initialize(), and have shouldShowNavButtons() be part of gHeader. The rest looks good.

Landed: http://hg.mozilla.org/mozilla-central/rev/41e0b2a73fd8

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101029 Thunderbird/3.3a1pre and with latest Minefield builds on OS X and Windows like Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101028 Firefox/4.0b8pre