The default bug view has changed. See this FAQ.

Enable global scope polluter in standards mode

RESOLVED FIXED in mozilla14

Status

()

Core
DOM
RESOLVED FIXED
6 years ago
8 months ago

People

(Reporter: Yakove, Assigned: bz)

Tracking

Trunk
mozilla14
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b9pre) Gecko/20110102 Firefox/4.0b9pre
Build Identifier: 

When added one file, should appear automatically form for uploading another one. It works on all browsers except FF

Reproducible: Always

Steps to Reproduce:
1. go to desuchan.ru/aa
2. choose file in form for uploading
3. that's all. New form does not appear
Actual Results:  
New form does not appear

Expected Results:  
You should see a new file upload form
Is it OK to upload random files for testing purposes?
(Reporter)

Comment 2

6 years ago
(In reply to comment #1)
> Is it OK to upload random files for testing purposes?

yes, it's OK, but the form designed for images
David, you don't have to upload anything to reproduce.  The new file control is supposed to appear as soon as you select a file in the existing file control.
The relevant JS error is likely this:

  Error: file_2_div is not defined
  Source File: http://desuchan.ru:800/aa/wakaba.html
  Line: 1

Line 1 is useless; all the text on the page is on one line.

The relevant markup (somewhat reduced) looks like this:

  <form>
    <table>
      <tbody>
        <tr>
          <td>
            <div id="file_1_div">
              <input type="file" onchange="more_files(file_2_div);">
            </div>
            <div id="file_2_div" style="display:none">
              <input type="file" name="file_2" size="35">
            </div>
          </td>
        </tr>
      </tbody>
    </table>
  </form>

Note the bareword "file_2_div" in that event handler.  In quirks mode, we map bareword lookups on the global object to id lookups and the like.  In standards mode, which is what the page is in, we don't do that.  If I switch the page into quirks mode, everything works.

It looks to me like http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-window-nameditem requires the behavior in all modes, though this part of the spec is not final and I think we should push back on having this global scope pollution in standards mode....

In any case, either using quirks mode or using getElementById if that's what you actually mean will make the page work without relying on non-standard browser behavior.
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → DOM
Ever confirmed: true
QA Contact: general → general
Summary: Next form for adding file not appear on desuchan.ru/aa → Should we have a global scope polluter in standards mode?
(In reply to comment #4)
> non-standard browser behavior.

That's a bit of a stretch now ;)

However, I would like it as well if we could avoid putting this horrible mess in standards mode.

For reference:

Oct 07 20:34:21 <Ms2ger>	Also, what's the cabal's opinion on making the named access on window quirks-only?
Oct 07 20:34:41 <gsnedders>	I would be amazed if that didn't break a large number of sites.
Oct 07 20:35:01 <Workshiva>	Large may not be large enough
Oct 07 20:35:08 <Ms2ger>	Gecko doesn't have it in standards mode
Oct 07 20:35:35 <gsnedders>	Ms2ger: Oh. That surprises me. Oh well.

Updated

6 years ago
Blocks: 630454
Duplicate of this bug: 658435
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
Duplicate of this bug: 737760
Created attachment 607869 [details] [diff] [review]
Make the global scope polluter work in standards mode too.

I give up.  WebKit and IE are never going to change this, Ian is never going to change the spec, and sites are actually starting to depend on this now.
Attachment #607869 - Flags: review?(jst)
Assignee: nobody → bzbarsky
Whiteboard: [need review]

Comment 9

5 years ago
(In reply to Boris Zbarsky (:bz) from comment #8) 
> I give up.  WebKit and IE are never going to change this, Ian is never going
> to change the spec, and sites are actually starting to depend on this now.

How about educating web masters of said sites if known?
Wouldn't that be better than caving in because the other two players are doing it wrong?

I don't even know what "Ian spec" you're referring to here, so please "take this with many grains of salt" =)
> How about educating web masters of said sites if known?

Have fun with that.  Start with Microsoft (see bug 737760).  And they'll just tell you that the code is perfectly per spec, which at the moment it is.

> Wouldn't that be better than caving in because the other two players are doing it wrong?

<shrug>.  I've spent several weeks of my life at this point on evangelism efforts here.  I no longer have time to spend on it, and no one else is doing anything about it.

> I don't even know what "Ian spec" you're referring to here

HTML5. Ian is the editor.
Comment on attachment 607869 [details] [diff] [review]
Make the global scope polluter work in standards mode too.

As sad as this makes me, I agree we should go ahead and do this.
Attachment #607869 - Flags: review?(jst) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/607f61e5b648
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla14
https://hg.mozilla.org/mozilla-central/rev/607f61e5b648
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Summary: Should we have a global scope polluter in standards mode? → Enable global scope polluter in standards mode
Blocks: 759995
You need to log in before you can comment on or make changes to this bug.