Closed Bug 192660 Opened 22 years ago Closed 21 years ago

Unable to access tax web page with 1.3b - 1.3a works

Categories

(Core :: DOM: Core & HTML, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: scriba, Assigned: asa)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210

After installing 1.3b, I can no longer access the TurboTax pages.
After reinstalling 1.3a I can access those same pages again.

Reproducible: Always

Steps to Reproduce:
1. Install 1.3b
2. Access
https://turbotaxweb.intuit.com/open/registration/auLogin_nn6.htm?customerSource=turbotaxcom&productid=&rotate=1
   and log in.
3. A "One moment..." page is displayed, informing the user that data is being
downloaded.
4. Wait for the downloads to complete.
Actual Results:  
The downloads end (it does not hang, just ends), but the "One moment..." page
remains.

Expected Results:  
The download should end and the web page should change to be that of the
TurboTax web application, allowing me to complete my tax return.

Alternating between 1.3a and 1.3b installations always results in the 1.3a
installation being able to log in and proceed without problems, and in the 1.3b
installation not being able to proceed.
I have this problem on 1.2.1 too. From what you say maybe it is fixed in 1.3a?

I get this in the JavaScript console:


Error: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMWindowInternal.unescape]"  nsresult:
"0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
https://qtwu1.intuit.com/secure/wtt_nn6.htm?uid=xxx&csrc=ttcomtoplink&prodid=16&state=xx&8259&app=qtws1&pt=26751
:: appendText :: line 4240"  data: no]
I have not checked 1.2.1, but, yes, it is fixed in 1.3a, and broken in 1.3b.
Well, I just tried 1.3a, 1.3b, and todays snapshot, and it doesn't work for me
on any of them. Is there something else different in your enviroment when you
run 1.3a (different user or profile or locale)?

It worked last year (don't remember which mozilla version, problably 1.1).

I think the Severity should be upgraded because I need to get my taxes done! :(

Nope, with the exception of libnullplugin.so, all other plugins I used are the
same for 1.3a and 1.3b, and I am using the same user profile.

I am using plugins for ShockwaveFlash, AdobeSVG 3.0, Acrobat 5, Plugger 4.0,
Realplayer 8.0, and j2sdk1.4.1_01.

I just switched to 1.3b (and back) to confirm this behaviour, and the results
were tha same: 1.3a is okay, 1.3b is not.

I have used that web site for my taxes for the last five years, but this year,
with 1.3b was the first time I had problems.  No doubt the web site's technology
changed, too.  I would have submitted this with a higher severity, but was able
to proceed to file my taxes with 1.3a.  Feel free to raise it if you are totally
stuck.
Hmmm. Do you get a similar JavaScript error as above in the console when it
doesn't work? Maybe it's a different problem, though the symptoms seem identical.
Okay, I did a bugzilla search for nsIDOMWindowInternal.unescape and it seems
this bug is already (sort of) known. Though I didn't see any recognition that it
actually breaks websites. 

See, for example,

http://bugzilla.mozilla.org/show_bug.cgi?id=44272

I try to have my locale and all various mozilla defaults set to UTF-8. By
manually changing View->Character Coding to 8859-1, I could procede with my taxes.

Perhaps you don't have a default charset set, and 1.3b changed the default to
UTF-8 (a good thing). But this bug needs fixing.
Okay, now I am stumped.

After reinstalling 1.3b again (same downloaded binary) the login, when the web
page just sat there, I entered "javascript:" and everything moved on just fine
from there.  The plugins don't matter bvecause I then tried it with just the
vanilla install as well with all the plugins reinstalled.

To make things even weirder, all subsequent logins succeeded, even without
entering "javascript:".  In any case, my java console showed no errors of the
nature described in Comment #1.

My character set under 1.3a and 1.3b is ISO-8859-1, without having to change it
from any other character set after installing 1.3b.

Following your comment, I set my character set to UTF-8 and the problem
reappeared.  Changing it back to ISO-8859-1 again let me proceed.
> Following your comment, I set my character set to UTF-8 and the problem
> reappeared.  Changing it back to ISO-8859-1 again let me proceed.

site problem then -> invalid
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Component: Browser-General → HTML: Form Submission
Resolution: --- → INVALID
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.