Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Slow Titlebar/Toolbar rendering when creating a new window

RESOLVED FIXED in Firefox 12

Status

()

Firefox
General
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Mehmet, Assigned: dao)

Tracking

({regression})

Trunk
Firefox 13
x86
All
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox12+ verified)

Details

(Whiteboard: [qa+])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 586771 [details]
four_screenshots.pdf

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7

Steps to reproduce:

Mac OS 10.6.8
Nightly: 12.0a1 (2012-01-07)

1) open single window
2) set in preferences 'when Nightliy starts: show my homepage' (e.g. www.google.com)
3) press fast CMD-T to open a new window


Actual results:

first the titlebar is shown and then the toolbar is shown


Expected results:

Titlebar and toolbar should be shown at the same time


***A PDF-file with four screenshots is attached***
(Reporter)

Comment 1

6 years ago
sorry I mean in step 3: press >>> CMD-N  <<<
(Assignee)

Updated

6 years ago
Blocks: 618770
Also happens on Windows, as mentioned in bug 720020
Status: UNCONFIRMED → NEW
Component: Untriaged → Theme
Ever confirmed: true
OS: Mac OS X → All
QA Contact: untriaged → theme
Summary: [Mac OS] Slow Titlebar/Toolbar rendering when, when creating a new window and 'always show the title bar' is disabled → Slow Titlebar/Toolbar rendering when creating a new window and 'always show the title bar' is disabled
Duplicate of this bug: 720020

Updated

6 years ago
tracking-firefox12: --- → ?
Keywords: regression
(Assignee)

Comment 4

6 years ago
I can't reproduce this (on Windows 7).
I can. Anything I can do to help debug it?

Comment 6

6 years ago
Tracking for 12, although I was able to reproduce the titlebar being rendered separately from the toolbar in FF10 on OS X. Presumably this bug is tracking a significant slowdown in the rendering though.
tracking-firefox12: ? → +

Comment 7

5 years ago
https://wiki.mozilla.org/Modules/All doesn't list a module owner for Themes. Who's in the best position to drive this investigation from the engineering side?
(Assignee)

Updated

5 years ago
Assignee: nobody → dao
Summary: Slow Titlebar/Toolbar rendering when creating a new window and 'always show the title bar' is disabled → Slow Titlebar/Toolbar rendering when creating a new window and 'always show the tab bar' is disabled
(Assignee)

Comment 8

5 years ago
I don't think this depends on the "always show the tab bar" pref.
Summary: Slow Titlebar/Toolbar rendering when creating a new window and 'always show the tab bar' is disabled → Slow Titlebar/Toolbar rendering when creating a new window
(Assignee)

Comment 9

5 years ago
Created attachment 603391 [details] [diff] [review]
patch

I think this helps... the tab container constructor runs before the load handler, so bug 618770 caused syncUI to run earlier.
Attachment #603391 - Flags: review?
(Assignee)

Updated

5 years ago
Attachment #603391 - Flags: review? → review?(felipc)
(Assignee)

Updated

5 years ago
Component: Theme → General
QA Contact: theme → general
Comment on attachment 603391 [details] [diff] [review]
patch

This fixes the bug for me, at least as originally reported in bug 720020 on the profile that I could reproduce the problem.

I see a different thing now: I don't see a first step with glass, but I see the browser window rendered before session store kicks in (i.e. with a blank tab at first). However, AFAICT this still happens without this patch on other profiles where I could not reproduce the bug. It seems that it's a different bug that was mitigated by this one? (as the first render of the browser was later, the initial image that I saw already had my app tabs restored)
Attachment #603391 - Flags: review?(felipc) → review+
(Assignee)

Comment 11

5 years ago
(In reply to Felipe Gomes (:felipe) from comment #10)
> I see a different thing now: I don't see a first step with glass, but I see
> the browser window rendered before session store kicks in (i.e. with a blank
> tab at first). However, AFAICT this still happens without this patch on
> other profiles where I could not reproduce the bug. It seems that it's a
> different bug that was mitigated by this one? (as the first render of the
> browser was later, the initial image that I saw already had my app tabs
> restored)

attachment 511080 [details] [diff] [review] did this, as far as I remember.
(Assignee)

Comment 12

5 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/120c201a6644
Target Milestone: --- → Firefox 13
(Assignee)

Updated

5 years ago
Attachment #603391 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/120c201a6644
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Depends on: 734273

Updated

5 years ago
Depends on: 734311

Updated

5 years ago
No longer depends on: 734311
Depends on: 734311
Comment on attachment 603391 [details] [diff] [review]
patch

[Triage Comment]
From reading the patch, this is low risk. It's also had a couple of days of bake time. Let's land on Aurora 12.
Attachment #603391 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
This has caused a serious regression under Linux.  (see bug 734273) I don't think landing on Aurora is very good idea.
(Assignee)

Comment 16

5 years ago
http://hg.mozilla.org/releases/mozilla-aurora/rev/e824347e2dbb
status-firefox12: --- → fixed
(Assignee)

Updated

5 years ago
No longer depends on: 734311

Updated

5 years ago
Depends on: 734836
(In reply to Bill Gianopoulos [:WG9s] from comment #15)
> This has caused a serious regression under Linux.  (see bug 734273) I don't
> think landing on Aurora is very good idea.

also on mac - bug 734836
(Assignee)

Updated

5 years ago
No longer depends on: 734836
(In reply to Alex Keybl [:akeybl] from comment #7)
> https://wiki.mozilla.org/Modules/All doesn't list a module owner for Themes.

"themes" are largely app-specific - the relevant module in this case is "Firefox".
Whiteboard: [qa+]
Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0

Verified in Firefox 12 beta 4. No display issue spotted now when opening new windows. Toolbar is rendered as normal.
status-firefox12: fixed → verified
You need to log in before you can comment on or make changes to this bug.