11537 - Value of wallet.Server pref is blank until clicked on

Status: VERIFIED WORKSFORME

(Toolkit :: Form Manager, defect, P3)

Description

[Paul MacQuiddy]

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.

Comment 1

[Stephen P. Morse]

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.

Comment 2

[Paul MacQuiddy]

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

Comment 3

[Stephen P. Morse]

For the same reason that we fetch things like chrome every time.  We do, don't
we?

Comment 4

[Paul MacQuiddy]

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

Comment 5

[David Hyatt]

Chrome is not going to reside remotely.  That feature was killed some time ago.
Chrome is always local.

Comment 6

[Paul MacQuiddy]

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. :-)

Comment 7

[Stephen P. Morse]

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.

Comment 8

[Paul MacQuiddy]

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

[Stephen P. Morse]

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.

Comment 10

[Stephen P. Morse]

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.

Comment 11

[Paul MacQuiddy]

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

[Stephen P. Morse]

Absolutely.  If there is no server indicated, then no download is attempted.

Comment 13

[Paul MacQuiddy]

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

[Stephen P. Morse]

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.

Comment 15

[Paul MacQuiddy]

Okay, I will stop bugging you about this. We will til after beta to see if
anyone is bothered by this.

Comment 16

[Paul MacQuiddy]

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

 and seeing if they are recreated?

Comment 17

[Stephen P. Morse]

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.

Comment 18

[Paul MacQuiddy]

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

[Stephen P. Morse]

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).

Comment 20

[Stephen P. Morse]

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

[neeti]

We are still using all.js to initialize preferences.

Comment 22

[Stephen P. Morse]

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

[Stephen P. Morse]

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

[Stephen P. Morse]

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 25

[buster]

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

[Stephen P. Morse]

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.

Comment 27

[buster]

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.

Comment 28

[buster]

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

[buster]

Attachment: a reduced version of the advanced pref panel. remove "fieldset" tag to see how it should look

Comment 30

[Peter Trudelle]

Mass-moving non-PDT+ bugs to M13

Comment 31

[Hixie (not reading bugmail)]

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

Comment 32

[sairuh (rarely reading bugmail)]

spam: in my testing realm, so reassigning qa contact to me, en masse.

Comment 33

[Eric Vaughan]

pushing to m14

Comment 34

[Peter Trudelle]

putting on beta1 radar

Comment 35

[Stephen P. Morse]

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.

Comment 36

[sairuh (rarely reading bugmail)]

verif.