The airport code autocompletion on the web page in the URL field does not work. I've narrowed it down to this script: http://www.aircanada.com/portal-web/js/flightStatusCommon.js. Once the page is loaded, it seems that the first function in that file (getGMTServerDate) is correctly defined. But the second variable definition in that file (oldSelectDate) does not exist in the global window. I'm not sure what's happening here, but it seems like everything after the first function in the js file is being ignored, which causes the |list| variable to not be defined, which breaks the autocompletion on the page. This is a regression in Firefox 4, and it's broken in trunk too.
Can you get us a nightly regression range?
Regression window:(cached m-c hourly): Works: http://hg.mozilla.org/mozilla-central/rev/008a0b8578db Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre ID:20100909231905 Fails: http://hg.mozilla.org/mozilla-central/rev/6ccd956d1df9 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre ID:20100909235647 Puhlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=008a0b8578db&tochange=6ccd956d1df9
I'm bisecting the range.
ehsan@ehsan-Macmini:~/moz/src$ hg bis -g The first bad revision is: changeset: 52363:2dc709fe2fcf user: David Zbarsky <firstname.lastname@example.org> date: Fri Sep 10 07:18:10 2010 +0200 summary: Bug 556007 (1/3) - Add list IDL attribute to HTMLInputElement. r=sicking a2.0=sicking I bet that this is happening because the page is assigning to a list property on the input element, and we're failing that assignment somehow. Is this expected?
The list property is readonly, so assignment should fail.
The real issue here is that the page has this code: <input type="text" autocomplete="off" onblur="FSSearchBlur(event)" onkeyup="list.processKeyEvent(event, list);" onkeydown="list.processKeyDownEvent(event, list);" onfocus="FSSearchFocus(this)" name="origin" id="origin" class=""> Note the bareword "list" use. But the <input> itself is on the scope chain when those event handlers run, and has a "list" property now, so the bareword "list" is now resolving to "this.list" instead of "window.list". The page expects it to be "window.list", so it breaks. The script that sets up window.list does: var list = new ListBox(); and lives at http://flightstatus.aircanada.com/portal-web/js/flightStatusCommon.js The only options here are to: 1) Back out the list stuff (and then push back on the spec somehow?). 2) Change the name of the list stuff from "list" to something that won't collide with web pages (and get the spec changed). 3) Special-case the name lookup for "list" somehow so that in this situation it's not found on the input. 4) Evangelize the site. I think no matter what, we need to ask Ian to stop adding properties on inputs with common/short names...
Oh, and if we go with #4, the simple fix for the page is s/list/window.list/ in those inline event handlers.
For what it's worth, in Opera 11 this site is broken in the same way for the same reason. It works in WebKit because they don't support @list yet. I just talked to hixie; he suggested we try evang first, then if that fails rename the property to suggestionlist or something. Thoughts?
I agree with Hixie here. Do we have any frequent Air Canada flyers?
FTR, a similar bug has been open two months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=644496 (and I agree with what has been said above: we should try to evang this)
OK, let's try that. Mounir, want to send them mail?
I can't reproduce the issue anymore and the link in comment 0 is dead. I that because aircanada.com gives another content to people in Europe or they magically fixed that?
The relevant link is the one in the url field. The comment 0 link is just wrong.
The only way I saw to call them about a website issue is via a phone number  and I don't really want to do that. Finding an email address in that kind of website is a real pain :-/  http://www.aircanada.com/en/customercare/viewingtips.html
I have a contact from a person working on the development team for this software (and this is how I found the bug!). I talked to her last night and she said that she's aware of the workaround, but I'll send her an email again.
(In reply to comment #15) > I have a contact from a person working on the development team for this > software (and this is how I found the bug!). I talked to her last night and > she said that she's aware of the workaround, but I'll send her an email > again. Can we assign the bug to you then? :)
(In reply to comment #16) > (In reply to comment #15) > > I have a contact from a person working on the development team for this > > software (and this is how I found the bug!). I talked to her last night and > > she said that she's aware of the workaround, but I'll send her an email > > again. > > Can we assign the bug to you then? :) Yes. Email sent.
I have confirmation from my contact that she's going to fix this issue. I will update the bug when I have the word from her on the fix being deployed.
I have word from my friend that the bug has been fixed on their side, and they just have to wait for it to go to production, which is apparently going to happen in late June.