about:preferences shows blank pages

VERIFIED FIXED in Firefox 34

Status

()

Firefox
Preferences
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: Octoploid, Assigned: aryx)

Tracking

Trunk
Firefox 35
Points:
---

Firefox Tracking Flags

(firefox32 unaffected, firefox33 unaffected, firefox34+ fixed, firefox35 fixed)

Details

(Whiteboard: [bugday-20140917])

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20140902141435

Steps to reproduce:

Open about:preferences


Actual results:

The preferences aren't shown. All I see is a blank page.
See attached screenshop
(Reporter)

Updated

4 years ago
Component: Untriaged → Preferences
Version: 34 Branch → Trunk
(Reporter)

Comment 1

4 years ago
Created attachment 8482668 [details]
2014-09-02-143029_1050x1680_scrot.png
Can you reproduce in a clean profile? Are there any errors in the browser console?
Flags: needinfo?(octoploid)
(Reporter)

Comment 3

4 years ago
(In reply to :Gijs Kruitbosch from comment #2)
> Can you reproduce in a clean profile? 

Yes.

> Are there any errors in the browser console?

No.
Flags: needinfo?(octoploid)

Comment 4

4 years ago
Any response when switching left-tabs?
It was normal in previous versions?

Looks like the #mainPrefPane is not loaded.

I have not reproduce the on latest Nightly in Windows 8.1.
Built from https://hg.mozilla.org/mozilla-central/rev/532b5fb77ba1.
I also can't reproduce on either OS X or Linux, on today's Nightly...
(Reporter)

Comment 6

4 years ago
(In reply to YF (Yang) from comment #4)
> Any response when switching left-tabs?

No.

> It was normal in previous versions?

Yes. I build trunk almost daily. It worked a few days ago.
(In reply to Octoploid from comment #6)
> (In reply to YF (Yang) from comment #4)
> > Any response when switching left-tabs?
> 
> No.
> 
> > It was normal in previous versions?
> 
> Yes. I build trunk almost daily. It worked a few days ago.

You build trunk yourself? Have you tried an official build as well, and does it have the same problem?
(Reporter)

Comment 8

4 years ago
(In reply to :Gijs Kruitbosch from comment #7)
> (In reply to Octoploid from comment #6)
> > (In reply to YF (Yang) from comment #4)
> > > Any response when switching left-tabs?
> > 
> > No.
> > 
> > > It was normal in previous versions?
> > 
> > Yes. I build trunk almost daily. It worked a few days ago.
> 
> You build trunk yourself? 

yes.

>Have you tried an official build as well, and does it have the same problem?

official build is fine (I tried latest nightly: Source Built from https://hg.mozilla.org/mozilla-central/rev/c360f3d1c00d)
(Reporter)

Comment 9

4 years ago
markus@x4 mozilla-central % cat .mozconfig
. $topsrcdir/browser/config/mozconfig

ac_add_options --prefix=/usr
ac_add_options --libdir=/usr/lib

ac_add_options --with-system-jpeg --with-pthreads --with-system-zlib
ac_add_options --with-system-bz2 --with-system-hunspell
ac_add_options --with-system-libevent
ac_add_options --with-system-lcms 
ac_add_options --with-system-png
ac_add_options --with-system-icu
ac_add_options --with-system-libvpx
ac_add_options --with-system-ffmpeg
ac_add_options --enable-system-ffi
ac_add_options --enable-system-pixman 
ac_add_options --enable-system-sqlite
ac_add_options --disable-gstreamer --disable-content-sandbox
#ac_add_options --with-system-nss --with-system-nspr

ac_add_options --disable-installer --disable-updater
ac_add_options --enable-official-branding
ac_add_options --enable-startup-notification
ac_add_options --disable-necko-wifi --disable-accessibility
ac_add_options --disable-elf-hack
ac_add_options --disable-sync
#ac_add_options --disable-stdcxx-compat
ac_add_options --disable-pulseaudio 
#ac_add_options --disable-unified-compilation

ac_add_options --disable-jemalloc
ac_add_options --enable-optimize=-O3 --disable-debug --disable-tests
ac_add_options --disable-debug-symbols
ac_add_options --disable-strip --disable-install-strip

ac_add_options --enable-default-toolkit=cairo-gtk2 --enable-system-cairo

ac_add_options --disable-crashreporter --disable-parental-controls
ac_add_options --disable-safe-browsing
#ac_add_options --disable-skia
#ac_add_options --disable-webrtc

mk_add_options MOZ_OBJDIR=/var/tmp/moz-build-dir
mk_add_options MOZ_MAKE_FLAGS="-j4"

export CFLAGS="-ffunction-sections -fdata-sections "
export CXXFLAGS="-ffunction-sections -fdata-sections "
(In reply to Octoploid from comment #9)
> markus@x4 mozilla-central % cat .mozconfig
> . $topsrcdir/browser/config/mozconfig


It's going to be one of these switches that broke... but it'll be tricky to figure out which one for anyone but you (also because it might depend on what versions of what system libs you're building with).

Can you try narrowing the regression range a bit?

Alternatively, considering it's specific to about:preferences, I would almost wonder if it's --disable-sync... - but that's just a guess. Could also try to bisect the mozconfig, I guess?
(Reporter)

Comment 11

4 years ago
Aug 26 16:04 build is fine
Aug 29 13:59 build is buggy

will bisect later.
(Reporter)

Comment 12

4 years ago
Started with:
800723ca6a75c18916bd5bdb43928bc8755d4d49 is the first bad commit
commit 800723ca6a75c18916bd5bdb43928bc8755d4d49
Author: Sebastian Hengst <archaeopteryx@coole-files.de>
Date:   Wed Aug 27 00:08:49 2014 +0200

    Bug 1016300 - Move inline scripts and styles into separate files for in-content preferences. r=Gijs
Are there any errors in the browser console after opening the preferences? If yes, can you please post them here?
(Reporter)

Comment 14

4 years ago
(In reply to Archaeopteryx [:aryx] from comment #13)
> Are there any errors in the browser console after opening the preferences?
> If yes, can you please post them here?

TypeError: document.getElementById(...) is null advanced.js:20
Created attachment 8482844 [details] [diff] [review]
patch, v1

The reason for this bug is that with updater disabled, the code failed because the node "showUpdateHistory" was not in the ifdef MOZ_UPDATER block.

Furthermore, I spotted that one creation of an event listener had the wrong node and wrong event type.

I built Firefox with installer and updater enabled and the preferences work without throwing an error.
Assignee: nobody → archaeopteryx
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #8482844 - Flags: review?(gijskruitbosch+bugs)
Comment on attachment 8482844 [details] [diff] [review]
patch, v1

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

r=me
Attachment #8482844 - Flags: review?(gijskruitbosch+bugs)
Attachment #8482844 - Flags: review+
Attachment #8482844 - Flags: checkin?
OS: Linux → All
Hardware: x86_64 → All
Hi, could you provide a try link thanks!
Flags: needinfo?(archaeopteryx)
Comment on attachment 8482844 [details] [diff] [review]
patch, v1

Please just use the checkin-needed keyword. It works better with automated bug marking tools.
Attachment #8482844 - Flags: checkin? → checkin+
https://hg.mozilla.org/mozilla-central/rev/4b56ee08673c
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Depends on: 1062907
[Tracking Requested - why for this release]: This is a regression from the changes in bug 1016300. Not fixing it on Aurora will break the Preferences in builds without updater.
status-firefox32: --- → unaffected
status-firefox33: --- → unaffected
status-firefox34: --- → affected
status-firefox35: --- → fixed
tracking-firefox34: --- → ?
No longer depends on: 1062907
Comment on attachment 8482844 [details] [diff] [review]
patch, v1

Approval Request Comment
[Feature/regressing bug #]: bug 1016300
[User impact if declined]: builds without updater (e.g. linux distro builds, I suspect?) have broken in-content preferences
[Describe test coverage new/current, TBPL]: nope
[Risks and why]: very low - in-content prefs are not the default, and this was mostly just moving ifdefs about.
[String/UUID change made/needed]: none
Attachment #8482844 - Flags: approval-mozilla-aurora?
(don't think we need to track this - but we should uplift)
(In reply to :Gijs Kruitbosch from comment #24)
> (don't think we need to track this - but we should uplift)

Tracking as I don't want to ship broken prefs to linux distros.
tracking-firefox34: ? → +
Comment on attachment 8482844 [details] [diff] [review]
patch, v1

Aurora+
Attachment #8482844 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Keywords: checkin-needed
Whiteboard: [push to aurora]
https://hg.mozilla.org/releases/mozilla-aurora/rev/868cc9e5e32a

FWIW, we have bug queries for branch uplifts. You don't need to set checkin-needed for it to be found :)
status-firefox34: affected → fixed
Keywords: checkin-needed
Whiteboard: [push to aurora]
Status: RESOLVED → VERIFIED
Whiteboard: [bugday-20140917]
You need to log in before you can comment on or make changes to this bug.