If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Value of wallet.Server pref is blank until clicked on

VERIFIED WORKSFORME

Status

()

Toolkit
Form Manager
P3
normal
VERIFIED WORKSFORME
18 years ago
8 months ago

People

(Reporter: Paul MacQuiddy, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: 9/13, Fieldset bug)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
If Wallet is turned off, perhaps we should not do the Netcenter tables download
at start-up.

If the download really doesn't affect start-up time at all, then we probably
don't need to do this.

Is there any reason this needs to be done everytime, instead of say, once a
month, or once every 25 launches or something.

Updated

18 years ago
Target Milestone: M11

Comment 1

18 years ago
Wallet being turned off simply means that we don't pop up a capture nag-box
every time the user submits a form.  But he can still initiate a pre-fill if he
likes.  So when he initiates such a pre-fill, we would be forced to fetch the
tables at that time and this will bring us right back to synchronous loading of
the tables which is what we wanted to avoid.

I won't close this out yet as invalid but will simply push it back to M11.  At
that time we can decide if this is a good idea or not.
(Reporter)

Comment 2

18 years ago
My other question was why we need to fetch the tables every time, are they
really going to be that dynamic?

Comment 3

18 years ago
For the same reason that we fetch things like chrome every time.  We do, don't
we?
(Reporter)

Comment 4

18 years ago
I actually have no idea. Hyatt, what is the policy on downloading new chrome
from Netcenter?

Comment 5

18 years ago
Chrome is not going to reside remotely.  That feature was killed some time ago.
Chrome is always local.
(Reporter)

Comment 6

18 years ago
What is wrong with just shipping with a default set of tables? When people
upgrade the browser, then they get a new set.

As you can tell, I'm a little concerned with the whole download from Netcenter
deal. :-)

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 7

18 years ago
No, this wouldn't cut it.  We want to be able to dynamically change the tables
so that we can continually be adding support for additional websites.
(Reporter)

Comment 8

18 years ago
Yes, I know why we do it. The question is if it is 'cost-effective' to do this
everytime you run your browser, just to get one or two new websites. We have
ways, via notifications and SmartUpdate, to do this also.

As you suggested, we can revisit this in a couple Milestones.

Comment 9

18 years ago
What I will eventually do is add a pref that gives the URL of the server from
which the tables should be fetched.  If the value of that pref is null, then we
don't download any tables.  I think this should satisfy the intent of this
request.

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 10

18 years ago
Pref has been added.  However it doesn't display properly in the pref panel and
can't be set to null in the pref panel due to bug 13316.  But that's a separate
issue with a separate bug report. The item requested in this report has been
accomplished and so I'm closing it out as fixed.
(Reporter)

Updated

18 years ago
Whiteboard: 9/13, investigating
(Reporter)

Comment 11

18 years ago
So, Steve, how is this pref supposed to work? Do I just blank out the field if I
don't want the Netcenter download?

Comment 12

18 years ago
Absolutely.  If there is no server indicated, then no download is attempted.
(Reporter)

Comment 13

18 years ago
It might be more clear and a bit cleaner to the end user if there was some type
of checkbox to turn it off. What do you think?

Comment 14

18 years ago
Do we really want this to be something the end user is concerned with.  For the
most part, we want them to download the tables if they are using wallet.  The
advanced user will figure out how not to if he so desires.  More importantly, IS
departments can now reconfigure systems so that they use their own server, or at
least a mirror site in their own country.
(Reporter)

Comment 15

18 years ago
Okay, I will stop bugging you about this. We will til after beta to see if
anyone is bothered by this.
(Reporter)

Comment 16

18 years ago
steve, how can I verify this without a debugger - somehow deleting the .tbl file

 and seeing if they are recreated?

Comment 17

18 years ago
Yes, that's probably the best way to verify it.  Delete the files, run with and
without the pref set and see that the files get created in one case and not in
the other.
(Reporter)

Comment 18

18 years ago
Steve, this pref isn't getting set by default. In other words, if I create a new
profile and go into the advanced pref pane, the wallet table field is empty (and
it doesn't show up in prefs.js file)

Comment 19

18 years ago
Oops, that's bad.  I'll check it out just as soon as my current build finishes.
If I see the same behavior, I'll reopen this report (and update the summary line
to reflect better what the problem is).

Updated

18 years ago
Status: RESOLVED → REOPENED
Summary: Disable Netcenter download if Wallet turned off? → Initial value of wallet.Server pref not getting set
Target Milestone: M11 → M12

Updated

18 years ago
Resolution: FIXED → ---

Updated

18 years ago
Status: REOPENED → ASSIGNED

Comment 20

18 years ago
Yep, it's just as paulmac described.  The initial value of
http://people.netscape.com/morse/wallet/ is not being set for this pref.  The
initial value is indeed given in all.js and this used to work

Matt & Neeti, are we no longer using all.js to initialize the preferences?  And,
if not, what is the current way of doing this?

Changing summary from "Disable Netcenter download if Wallet turned off?" to
"Initial value of wallet.Server pref not getting set" and reopening this report.

Comment 21

18 years ago
We are still using all.js to initialize preferences.

Comment 22

18 years ago
The fact that no entry is put into prefs.js is normal since we are talking about
the default value.  The only time a value is put into prefs.js is if the current
value is other than the default.

The default is indeed being set correctly.  The only bug is that the prefs panel
does not appear to be showing the value.  It's actually there and if you click
on the box the value will suddenly appear.  Very strange.

At first I'd say this was a problem with text boxes in preference panel.  But
the only other text box, homepage location under navigator, does not have this
problem.

Comment 23

18 years ago
dp thought that this might have something to do with a webshell not being
created until the text gets focus.  Copying buster on this -- buster, do you
have any words of advice here.  To see what we are talking about, go to advanced
preferences and click on the wallet server text field.  The field appears to be
blank but when you click on it, its value suddenly appears.

Comment 24

18 years ago
dp thought that this might have something to do with a webshell not being
created until the text gets focus.  Copying buster on this -- buster, do you
have any words of advice here.  To see what we are talking about, go to advanced
preferences and click on the wallet server text field.  The field appears to be
blank but when you click on it, its value suddenly appears.

Updated

18 years ago
Assignee: morse → buster
Status: ASSIGNED → NEW
Summary: Initial value of wallet.Server pref not getting set → Value of wallet.Server pref is blank until clicked on

Comment 25

18 years ago
so, here's the weird part.  nsGfxTextControlFrame::Reflow NEVER gets called when
this prefs panel pops up.  No relfow, no default content.  How on earth can this
be getting laid out if there's no reflow happening, not even an initial reflow?
cc'ing hyatt and waterson, maybe you guys have some clue about how this could
be?

Comment 26

18 years ago
Reassigning to buster per our phone conversation.  For reference, the xul code
that puts up the advanced preference pane (which demonstrates this bug) is in
/xpfe/components/prefwindow/resources/content/pref-advanced.xul and the one that
puts up the navigator preference pane (for which the text field works fine) in
in /xpfe/components/prefwindow/resources/content/pref-navigator.xul

Changing summary line to better reflect what the current bug is.

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 27

18 years ago
ok, it's not that reflow isn't getting called.  duh.

it's that the pseudo-content has no "primary" frame.  that's my fault, I will
fix it soon.

Updated

18 years ago
Assignee: buster → evaughan
Status: ASSIGNED → NEW

Comment 28

18 years ago
ok, now we're getting somewhere.  I fixed the pseudo content primary frame
problem (to be checked in as soon as I can get a reviewer and a clean tree).  I
get further, but I still don't get the reflow I expect.  I believe this is
because of the fieldset around the text control.  I've attached a minimized xul
test case that shows the problem.
If you use the attached xul file to replace the advanced prefs panel, you'll see
a single empty text control.  If you remove the fieldset around the text
control, and reload, you'll see the default content filled in.
reassigning to evaughan to investigate why the fieldset is short-circuiting the
content changed reflow generated from
nsGfxTextControlFrame::SetTextControlFrameState() line 914.
Just a first guess:  I don't see any provision for incremental reflows in
fieldset frame's Reflow() method.  Most frames have a special case for
incremental reflow where the next target is gotten from the reflow state and the
incremental reflow is passed directly to that target, often with a special case
for target==this.  cc'ing chris and troy in case they can shed any additional
light.

Comment 29

18 years ago
Created attachment 2791 [details]
a reduced version of the advanced pref panel.  remove "fieldset" tag to see how it should look

Updated

18 years ago
Severity: enhancement → normal

Comment 30

18 years ago
Mass-moving non-PDT+ bugs to M13
See also:
   bug 10434 legend.form is always null
   bug 18357 Legend align does not work in Japanese
   bug 21638 {css1} Cannot style FIELDSET element outside FORM elements

Updated

18 years ago
Status: NEW → ASSIGNED
Whiteboard: 9/13, investigating → 9/13, Fieldset bug

Updated

18 years ago
Blocks: 23156
QA Contact: paulmac → sairuh
spam: in my testing realm, so reassigning qa contact to me, en masse.

Updated

18 years ago
Target Milestone: M13 → M14

Comment 33

18 years ago
pushing to m14

Comment 34

18 years ago
putting on beta1 radar

Comment 35

18 years ago
I just read over this bug report and I believe it is all fixed.  Initially this 
was a report about not downloading wallet tables at startup.  That was then 
fixed. Then the report morphed into the fact that the name of the server from 
which the files are to be downloaded was not visible in the preference panel.  
But that too has long been fixed.  So I think this report just got forgotten 
about.  Closing this out as works for me.  Unless it has morphed into yet 
something else, in which case it would be a good idea to report that in a new 
bug report.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME
verif.
Status: RESOLVED → VERIFIED
Assignee: eric → nobody
Component: Form Manager → Form Manager
Product: Core → Toolkit
QA Contact: bugzilla → form.manager
Target Milestone: M14 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.