Closed Bug 588462 Opened 15 years ago Closed 15 years ago

The controls in this Telerik RadControls demo stopped working when HTML5 enabled

Categories

(Core :: DOM: HTML Parser, defect, P2)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla2.0b7
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: cramhead, Assigned: hsivonen)

References

(
URL
)

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b4pre) Gecko/20100817 Minefield/4.0b4pre ( .NET CLR 3.5.30729; .NET4.0E) Build Identifier: Normal control interaction is blocked after the first interaction Reproducible: Always Steps to Reproduce: 1.Visit the URL 2.Click on a calendar entry 3.Attempt to do anything other the close the popup. Functionality such as datepickers, subsequent popups and dropdowns work on previous version of FF3.5 Stable Actual Results: Only checkboxes and textfields seem to function, all other controls do not work correctly Expected Results: All controls on the modal work In development of a scheduling that uses this control I first noticed the problem after adding an updatepanel and enablingPartialPostbacks
I can reproduce if on step 2 I double-click instead of clicking - works in Firefox 3.6.8, fails in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b6pre) Gecko/20100901 Firefox/4.0b6pre. It would be helpful to know when exactly this regressed - if you have time, your help would be appreciated, see http://new.quality.mozilla.org/documents-home/bugs-docs/bug-triaging-guidelines/finding-regression-windows
Keywords: regression, regressionwindow-wanted
OS: Windows 7 → All
Summary: Subsequent events don't fire → The controls in this Telerik RadControls demo stopped working in Firefox 4
Version: unspecified → Trunk
Bug 554905 shows a similiar issue with popups of the same toolkit. Could eventually be related.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Regression range between 10050303 and 10050403. PASS: http://hg.mozilla.org/mozilla-central/rev/83c887dff0da FAIL: http://hg.mozilla.org/mozilla-central/rev/d6bb0f9e9519 Check-ins: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83c887dff0da&tochange=d6bb0f9e9519 This regression is caused by bug 373864 which enabled the html5 parser by default.
Blocks: html5-parsing
blocking2.0: --- → ?
Keywords: regressionwindow-wanted
Summary: The controls in this Telerik RadControls demo stopped working in Firefox 4 → The controls in this Telerik RadControls demo stopped working when HTML5 enabled
Component: General → HTML: Parser
QA Contact: general → parser
Henri, can you investigate this? Blocking until we know more about what this is about.
Assignee: nobody → hsivonen
blocking2.0: ? → final+
Something in my patch queue fixes this. My guess is that this is a duplicate of bug 585819.
Depends on: 585819
Priority: -- → P2
Bug 585819 landed. Worth retesting this after the next round of nightlies.
(In reply to comment #7) > The latest tinderbox build doesn't fix the problem for me: > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx/1283777321/ Thanks. This has to be a duplicate of bug 585819 then.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
(In reply to comment #8) > (In reply to comment #7) > > The latest tinderbox build doesn't fix the problem for me: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx/1283777321/ > > Thanks. This has to be a duplicate of bug 585819 then. Why? I said it's *not* fixed. So it can barely be a dupe of bug 585819. Tested with Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100906 Firefox/4.0b6pre
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Sorry, I misread what you said in comment 7. I also had the fix for bug 585620 in my tree, so that one might have been the one fixing this.
No longer depends on: 585819
I isolated the patch the fixes this. It's the one for bug 591981.
Depends on: 591981
The dependency landed http://hg.mozilla.org/mozilla-central/rev/0ab712643a66
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100918 Firefox/4.0b7pre Are the tests from bug 591981 sufficient to cover this particular issue?
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Target Milestone: --- → mozilla2.0b7
(In reply to comment #13) > Are the tests from bug 591981 sufficient to cover this particular issue? I don't know, because I didn't investigate why the fix for bug 591981 fixed this bug, too. I just observed that it did.
Bug 591981 has been backed-out.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Bug 591981 relanded.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Verified again with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100922 Firefox/4.0b7pre
Status: RESOLVED → VERIFIED
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Bug 591981 landed the third time.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101023 Firefox/4.0b8pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.