Closed Bug 964257 Opened 6 years ago Closed 6 years ago

Location bar briefly shows placeholder text when exiting customization mode

Categories

(Firefox :: Toolbars and Customization, defect)

29 Branch
x86_64
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 30
Tracking Status
firefox29 --- verified
firefox30 --- verified

People

(Reporter: phlsa, Assigned: bwinton)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P-])

Attachments

(1 file)

When exiting customization mode, the location bar briefly shows its placeholder text ("Search or enter address") before showing the address of the tab.
This contributes to the transition looking wonky on OS X.
Whiteboard: [Australis:P?] → [Australis:P-]
Okay, let's see how people like this.  (Based on an idea by mconley.)
Assignee: nobody → bwinton
Attachment #8385343 - Flags: ui-review?(philipp)
Attachment #8385343 - Flags: review?(mconley)
Note: This should also fix bug 964279.
Comment on attachment 8385343 [details] [diff] [review]
Close the tab before flipping the deck away from the customize pane.

Review of attachment 8385343 [details] [diff] [review]:
-----------------------------------------------------------------

I'm good with this, but we should watch the CART numbers for the exit times.
Attachment #8385343 - Flags: review?(mconley) → review+
Keywords: checkin-needed
Comment on attachment 8385343 [details] [diff] [review]
Close the tab before flipping the deck away from the customize pane.

>+      browser.parentNode.selectedPanel = browser;

What is that? This doesn't seem to make any sense.
The parent of the element with id="browser" is the content-deck, which is a XUL deck that has two child elements - the browser, and the customization container.

browser.parentNode.selectedPanel = browser sets the deck back to the browser from the customization container.
Ah, I thought this was some sort of actual browser or tabbrowser, but it's really something like a "tabbrowserContainer".
remote:   https://hg.mozilla.org/integration/fx-team/rev/092b3b1a185c
Whiteboard: [Australis:P-] → [Australis:P-][fixed-in-fx-team]
See Also: → 964279
https://hg.mozilla.org/mozilla-central/rev/092b3b1a185c
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P-][fixed-in-fx-team] → [Australis:P-]
Target Milestone: --- → Firefox 30
Comment on attachment 8385343 [details] [diff] [review]
Close the tab before flipping the deck away from the customize pane.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 

Australis!


User impact if declined: 

A distracting white flash when exiting customize mode.


Testing completed (on m-c, etc.): 

Lots of testing on mozilla-central.


Risk to taking this patch (and alternatives if risky): 

Very low.


String or IDL/UUID changes made by this patch:

None.
Attachment #8385343 - Flags: approval-mozilla-aurora?
Attachment #8385343 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Status: RESOLVED → VERIFIED
This issue is back in the current Nightly, along with some other (minor) polish issues in the customization transition.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Hm - this might have to do with some of the recent work on cleaning up the back / forward buttons... can you find the first Nightly that this got introduced, phlsa?
Flags: needinfo?(philipp)
Please only reopen bugs when the patch was either backed out or already ineffective at the time it landed. If an issue reappears weeks later, please file a new bug. Makes it much easier to keep track of when and why things regressed and what patches landed when.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
(In reply to Mike Conley (:mconley) from comment #12)
> Hm - this might have to do with some of the recent work on cleaning up the
> back / forward buttons... can you find the first Nightly that this got
> introduced, phlsa?

Hm, this is strange. I tried to narrow down the range using mozregression, and I couldn't find a single release where it worked (I looked all the way back to early March).
This can mean two things:
- I suck at mozregression
- It was never actually fixed completely


(In reply to Dão Gottwald [:dao] from comment #13)
> Please only reopen bugs when the patch was either backed out or already
> ineffective at the time it landed. If an issue reappears weeks later, please
> file a new bug. Makes it much easier to keep track of when and why things
> regressed and what patches landed when.

Alright, thanks for the clarification! So I'll just keep the discussion here until we're sure this was actually fixed at some point.
Flags: needinfo?(philipp)
You need to log in before you can comment on or make changes to this bug.