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




16 years ago
15 years ago


(Reporter: scriba, Assigned: asa)



Firefox Tracking Flags

(Not tracked)





16 years ago
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
   and log in.
3. A "One moment..." page is displayed, informing the user that data is being
4. Wait for the downloads to complete.
Actual Results:  
The downloads end (it does not hang, just ends), but the "One moment..." page

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.

Comment 1

16 years ago
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 ::
:: appendText :: line 4240"  data: no]

Comment 2

16 years ago
I have not checked 1.2.1, but, yes, it is fixed in 1.3a, and broken in 1.3b.

Comment 3

16 years ago
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! :(


Comment 4

16 years ago
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

Comment 5

16 years ago
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.

Comment 6

16 years ago
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,


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.

Comment 7

16 years ago
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.

Comment 8

15 years ago
> 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
Last Resolved: 15 years ago
Component: Browser-General → HTML: Form Submission
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.