onchange event is not fired when restoring maximized window

RESOLVED WORKSFORME

Status

()

Core
DOM: Events
RESOLVED WORKSFORME
12 years ago
2 years ago

People

(Reporter: artur.signell, Unassigned)

Tracking

({testcase})

Trunk
x86
Windows XP
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fi; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fi; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

When filling in a text field in a maximized browser window and restoring the window size before moving to another field causes the onchange event never to be sent.

Reproducible: Always

Steps to Reproduce:
1. Create a page with an <input type="text" onchange="alert('changed');"/> tag.
2. Load page into firefox.
3. Maximize firefox.
4. Write some text in text field.
5. Restore window size.
6. Click somewhere outside text field.

Actual Results:  
none

Expected Results:  
an alert popup saying "changed"

Only seems to happen in windows version.

Updated

12 years ago
Assignee: nobody → events
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch

Comment 1

12 years ago
This seems to be a valid bug. I searched for a duplicate and couldn't find any.
I confirm the reporter's findings with Firefox 2.0 RC2 rv:1.8.1 build 20061003 under XP Pro SP2.

The reverse will get the expected results. e.g.: Load page, resize window to be non-maximized, enter data, maximize window, click outside input and the alert will pop up.

Testcase coming up

Comment 2

12 years ago
Created attachment 242138 [details]
Minimized self-explanatory testcase

Comment 3

12 years ago
I get the expected results with IE 7 RC1 and Opera 9.02.

I will check with a trunk build (rv:1.9a1) later... unless someone does it before me.

Comment 4

12 years ago
I get the actual results with Seamonkey 1.5a rv:1.9a1 build 2006101708 under XP Pro SP2.

version -> Trunk

CONFIRMING
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Version: 1.8 Branch → Trunk
Assignee: events → nobody
QA Contact: ian → events

Comment 5

7 years ago
This seems to be a more general error -- probably some design fault -- because, there's other ways in which the event fails to be raised. For example, see this use case:

1. Firefox 10 on Windows 7 32 bits;
2. Type something on a field;
3. Select the text and right-click to it;
4. Select Delete from the context menu;
5. Click on the address bar (this makes the input lose the focus);

The change event was lost.

I'm yet to see Mozilla fixing a non critical error but I'm hoping not to die young, so...

Comment 6

2 years ago
Windows 7, 8.x and Windows 10 users: Is this bug still happening?

When trying attachment 242138 [details], I get expected results with Firefox 50.0a1 buildID=20160616021437 under Linux 3.13.0-88-generic x86_64, Qt: 4.8.6, KDE 4.13.3.

Comment 7

2 years ago
(In reply to Gérard Talbot from comment #6)
> Windows 7, 8.x and Windows 10 users: Is this bug still happening?
 
When trying attachment 242138 [details], I get expected results with Firefox 47.0.1 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 build ID=20160623154057) under Windows 7 SP1.

Comment 8

2 years ago
(In reply to Filipe Martins from comment #5)
> 1. Firefox 10 on Windows 7 32 bits;
> 2. Type something on a field;
> 3. Select the text and right-click to it;
> 4. Select Delete from the context menu;
> 5. Click on the address bar (this makes the input lose the focus);
> 
> The change event was lost.

That would be another bug report....

I tried Filipe's steps with Firefox 47 and Firefox 50 (nightly build) and the change event was *not* lost.


(In reply to Carlos Alén Silva from comment #7)
> When trying attachment 242138 [details], I get expected results with Firefox
> 47.0.1 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101
> Firefox/47.0 build ID=20160623154057) under Windows 7 SP1.

Thank you Carlos! 

I am resolving this bug as WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.