Closed Bug 7456 Opened 25 years ago Closed 25 years ago

No error-checking in Profile Manager code

Categories

(Core Graveyard :: Profile: BackEnd, defect, P3)

Product:
Core Graveyard
Component:
Profile: BackEnd
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: leon, Assigned: racham)

References

(
URL
)

Details

Attachments

(2 files)

Stack trace
8.38 KB, text/plain
Details
Minimal Test Case
182 bytes, text/html
Details 
Bugs:

Hotmail says "can't do, have you forgotten your password?"

Yahoo logs you in but the URL for checking your mail is *empty* (and so are some others); when you click it, the browser tries to view "http://" and does nothing (leaves the page displayed).

Other:

BTW, when I logged in to BugZilla, I had no password; when I hit "Back" I had to retype the email address as well. Is that supposed to happen?

BTW, When the above paragraph was the last line in this entry box, a downarrow from "when" - which should (IMHO) land on "supposed" - line wrapped between "that" and "supposed" - did nothing.

Display update is very messy - some bloopers are never cleaned up (e.g. scrolling by lines leave unreadable crud, scrolling by pages with the scrollbar works fine).

Some <input> boxes were too large and/or not where all other browsers reckon they should be; e.g. "login" boxes on SlashDot were too large, "Search" box in Yahoo News was in middle of screen instead of middle of right column.

Plaudits:

Works faster than earlier Mozillas, displays images better than NS 4.6, still *much* lighter! Oh, and doesn't trash the system like IE. (-:

More details:

This is a RH 6.0 install running kernel 2.2.9 under Gnome + E on an AMD K6-II-300; browser is Mozilla M6; field "Version" at top contains "other" and I can't change that.
Component: Viewer App → Front End
Product: Browser → MailNews
QA Contact: leger → lchiang
lchiang, setting QA Contact to you for investigation.
QA Contact: lchiang → leger
Jan, this has nothing to do with the mail/news component or code.  This has to
do with accessing items on a given web page (ie. hotmail or yahoo).  So, I'm
setting back to you :-)
Component: Front End → Apprunner
Product: MailNews → Browser
QA Contact: leger → beppe
beppe, please set QA Contact.
You can see blank yahoo links, somewhat fuzzily, at:

http://kundip.copl.com.au/snapshot/199906/02/_hhh_22.html

in the 22:45 timeslot
PPS, in case it matters, this was a masqueraded connection. The NS browsers at
the site usually run through Squid on the proxy/webserver/DNS/everthingelse
machine but work fine unproxied.
Assignee: rickg → karnaze
Chris -- this appears to be a forms submission bug.
Assignee: karnaze → pollmann
Reassignig to Eric.
Component: Apprunner → Form Submission
QA Contact: beppe → cpratt
Updating QA Contact
*** Bug 7881 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
No fun.  When I try to log into Hotmail (or register for an account) Gecko just
spins after I click on the Submit button:

Reading file...
Reading file...Done
Reading file...
Reading file...Done
...ad infinitum
Attached file Stack trace — 

    
  
Assignee: pollmann → morse
Status: ASSIGNED → NEW

    
    

    
  
This is infinite looping inside of wallet_Initialize().  I've attached a stack
trace.  I set a breakpoint at this loop and watched it spin inside MSVC:

while (!Wallet_SetKey(PR_FALSE)) {
  if (!Wallet_Confirm(message)) {
    Wallet_Alert(failed);
    PR_FREEIF(message);
    PR_FREEIF(failed);
    return;
  }
}

    
    

    
  

      
      
      
      

        Attached file
          
        Minimal Test Case
        — 
      

    


  

    
  
OS: Linux → All
Hardware: PC → All

    
    

    
  
I've attached this minimal test case:
(also at http://blueviper.mcom.com/forms/submitspin.html)

<HTML>
 <BODY>
  <FORM ACTION="/cgi/echo.cgi">

  <INPUT NAME="a" VALUE="foo">
  <INPUT NAME="b">
  <INPUT NAME="c">

  <INPUT TYPE="submit" VALUE="Save">
  </FORM>
 </BODY>
</HTML>

Tested on WinNT and Linux.  This case always infinite loops for me.  It didn't
matter which input had a value, but if I deleted any one of the inputs, or if
none of them had values, it will not infinite loop - Go figure.  :)

    
  
Status: NEW → ASSIGNED

    
  
Assignee: morse → mcmullen
Status: ASSIGNED → NEW

    
    

    
  
I'm a little confused by this report because it starts off by talking about lots
of things with no clear bug defined.  I will assume that the bug is the test
case that pollmann has presented on 6-20 at
http://blueviper.mcom.com/forms/submitspin.html and I will ignore all other
comments in the report.

First, pollmann states that the test case loops in wallet initialization code.
That did not happen when I tested it using a build from a tree that I pulled
last night.  Eric's symptoms do indeed sound familiar but I believe they got
fixed somewhere along the line.  So I will discard those symptoms as well
(otherwise I would have to mark this report as "works-for-me".

Second, I do get a problem when I try to save the form that pollman presented.
I get the pop-up box saying "do you want to save" and if I press OK I get a
debug failure (stacktrace below).  But this is for debug builds only -- if I
instruct the debugger to continue executing (need to do this about four times
because this failure occurs more than once) everything is fine.  Also there
should be no failure at all in release builds.

The problem has to do with the changes that mcmullen made on 6-17 whereby there
is no longer any initial profile created.  My registry indicated that I should
have had a profile but, since I pulled a brand new tree, I had none.  Thus
anything that involves the use of a profile will not work.  If I deleted my
mozregistry.dat file and ran again, the failure went away.

So I am reassigning this bug to mcmullen

(BTW, to answer Eric's question as to why three inputs caused the failure but
for any fewer there was no failure.  That's because wallet considers a form with
less than three inputs as being too trivial to save.  Otherwise it would be
asking "do you want to save" everytime you ran a search engine.)
NTDLL! 77f76274()
nsDebug::Error(char * 0x01f317e4, char * 0x01f317b8, int 1213) line 178 + 13
bytes
wallet_FetchFromNetCenter(char * 0x01f318e8, char * 0x01f318d4) line 1213 + 21
bytes
wallet_FetchSchemaConcatFromNetCenter() line 1259 + 15 bytes
wallet_Initialize() line 1486
WLLT_Capture(nsIDocument * 0x02196450, nsString {...}, nsString {...}, nsString
{...}) line 2274
nsWalletlibService::WALLET_Capture(nsWalletlibService * const 0x0124ea30,
nsIDocument * 0x02196450, nsString {...}, nsString {...}, nsString {...}) line
87 + 54 bytes
nsFormFrame::ProcessAsURLEncoded(int 0, nsString & {...}, nsIFormControlFrame *
0x0000012c) line 834 + 79 bytes
nsFormFrame::OnSubmit(nsFormFrame * const 0x01007ec0, nsIPresContext *
0x00fc6930, nsIFrame * 0x77e711b8) line 476
nsButtonControlFrame::MouseClicked(nsIPresContext * 0x00000000) line 353
nsFormControlFrame::HandleEvent(nsFormControlFrame * const 0x010f2510,
nsIPresContext & {...}, nsGUIEvent * 0x10210016, nsEventStatus &) line 605
nsButtonControlFrame::HandleEvent(nsButtonControlFrame * const 0x00000000,
nsIPresContext & {...}, nsGUIEvent * 0x00000000, nsEventStatus &) line 533
PresShell::HandleEvent(PresShell * const 0xffffffff, nsIView * 0x0012f974,
nsGUIEvent * 0x102115b0, nsEventStatus &) line 2043 + 38 bytes
nsView::HandleEvent(nsView * const 0x0012fa6c, nsGUIEvent * 0x00000002, unsigned
int 1243864, nsEventStatus &, int & 0) line 833
nsView::HandleEvent(nsView * const 0x01fe53e0, nsGUIEvent * 0x10070e94, unsigned
int 33444832, nsEventStatus &, int &) line 818
nsView::HandleEvent(nsView * const 0x00b40898, nsGUIEvent * 0xffffffeb, unsigned
int 1, nsEventStatus &, int & 66634) line 818
nsView::HandleEvent(nsView * const 0x00000143, nsGUIEvent * 0x0012fb58, unsigned
int 28958371, nsEventStatus &, int & 29944120) line 818
nsView::HandleEvent(nsView * const 0x00000000, nsGUIEvent * 0x77f3b874, unsigned
int 2012466696, nsEventStatus &, int & 0) line 818
nsViewManager::DispatchEvent(nsViewManager * const 0x0012fd38, nsGUIEvent *
0x00000143, nsEventStatus &) line 1735
HandleEvent(nsGUIEvent * 0x0012fd38) line 67
nsWindow::DispatchEvent(nsWindow * const 0x00f9a120, nsGUIEvent * 0x00000004,
nsEventStatus &) line 408 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x00f99960) line 429
nsWindow::DispatchMouseEvent(unsigned int 32357323, nsPoint * 0x000023af) line
3007 + 15 bytes
nsWindow::ProcessMessage(unsigned int 24, unsigned int 11797312, long 8, long *
0x00000000) line 2369 + 24 bytes
nsWindow::WindowProc(void * 0x00000000, unsigned int 0, unsigned int 0, long
1244628) line 471 + 27 bytes
USER32! 77e71268()

    
  
Assignee: mcmullen → selmer

    
    

    
  
if this is what the problem is, then I'm reassigning it to selmer. Here's what I
think needs to be done (as is done in Communicator 4.5, at least the Macintosh
version).

If a profile directory is in the registry, it should always be tested immediately
to see if it exists. This situation is common on the Macintosh after moving one's
files to a new machine, for example (I did this just last week, and was grateful
for the friendly handling that Comm 4.5 provided for this situation).

If the profile directory in the registry does not exist on disk, the profile
manager should ask the user whether she wants to (1) delete the profile, or (2)
browse to locate the correct directory. If the user chooses (1), then the profile
wizard/picker logic should restart at the top. If she chooses (2), the registry
info should be updated with the new directory.

    
  
Assignee: selmer → racham
Component: Form Submission → Profile Manager

    
    

    
  
Overall, I agree with John's comments.  One difference I have is that all bad
profiles should be discovered before showing any UI to the user.  The UI to show
at that point is the profile manager with a button allowing them to correct the
broken profiles (and they should be marked similar to what we're doing with
migration profiles.)

This gives the proper behavior with the minimal amount of new code and UI fuss
for the user (especially in the case of multiple bad profiles.)

Bhuvan, if this can be fit into M8, that would be a good thing.

    
  
Status: NEW → ASSIGNED
Target Milestone: M9

    
    

    
  
Can't currently bump any M8 work for this.  Workaround is to delete your
mozregistry.dat file when this happens.

    
    

    
  
Not quite sure if this is related but when attempting to read indivual messages
in yahoo mail if get an empty table that says:
llspacing=0 cellpadding=0 width="100%">
i dont know what is causing the renderer to choke here but it does.

    
  
Target Milestone: M9 → M10

    
    

    
  
This calls for handling the inconsistencies that user actions might create with
respect to the profile information. A UI to prompt the appropriate actions need
to associated with this. Setting TFV to M10.

    
    

    
  
*** Bug 9600 has been marked as a duplicate of this bug. ***

    
  
QA Contact: cpratt → gbush
Summary: hotmail refuses login, yahoo allows login, mail link is *empty* → No error-checking in Profile Manager code

    
    

    
  
I am taking the liberty of updating the summary, which was no longer relevant.

Another error case is when you create a new profile in a directory that has a
profile (or at least some data) already in it.

    
    

    
  
P3s aren't going to make it in M10.  Bulk moving to M11.

    
  
Blocks: 12696

    
  
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED

    
    

    
  
A fix was already checked in. If the profile directory gets deleted or does not
exists on the machine for some reason, then that directory gets created and is
populated with default values.

    
  
Status: RESOLVED → VERIFIED

    
    

    
  
all platforms build 19990924

    
  
Target Milestone: M11 → M10

    
  
Component: Profile Manager → Profile Manager BackEnd

    
    

    
  
Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: