'Next' button doesn't change to active when dragging an URL into text field

RESOLVED FIXED in 0.9

Status

Calendar
General
--
trivial
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: Carsten, Assigned: Robin Edrenius)

Tracking

unspecified

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051104 Mozilla Sunbird/0.3a1

When I create a new remote calendar, I can drag a hyperlink (URL) from a webbrowser into the textfield. The URL appears correctly, however the 'Next'-button doesn't change it's visual "disabled" state. That is, it stay greyed, but can still be clicked to proceed.

Reproducible: Always

Steps to Reproduce:
1. File -> New Calendar: select 'Remote'
2. Drag a hyperlink from a webbrowser into the text field
3. -> Next button is still grey

Actual Results:  
The process can be completed normally as the button is enabled after the text field is filled.

Expected Results:  
The text on the 'next' button should turn black as soon as I drag the URL into the text field
(Assignee)

Comment 1

12 years ago
Created attachment 211484 [details] [diff] [review]
add a check for ondragexit

This adds a check for ondragexit.

(I'm not sure if there are any more cases we don't cover, but those can be handled  as they show up)
Assignee: nobody → robin.edrenius
Status: UNCONFIRMED → ASSIGNED
Attachment #211484 - Flags: first-review?(jminta)

Comment 2

12 years ago
Comment on attachment 211484 [details] [diff] [review]
add a check for ondragexit

At the very least, I think we want ondrop, not ondragexit.  However, this feels more like a toolkit bug than something we should be fixing in our own code with work-arounds.

Updated

12 years ago
Depends on: 326806

Updated

12 years ago
Depends on: 128066
No longer depends on: 326806

Comment 3

12 years ago
Please ping me again about this if we approach 0.3 final without bug 128066 being solved.  I'm ok with releasing alphas and betas with this bug, since the work-around is pretty easy. If we approach final before that bug is solved, then will introduce some sort of hack, probably like what redrenius has proposed.

Comment 4

11 years ago
Comment on attachment 211484 [details] [diff] [review]
add a check for ondragexit

r- based on comment 2.
Attachment #211484 - Flags: first-review?(jminta) → first-review-
Assignee: robin.edrenius → nobody
Status: ASSIGNED → NEW
Component: Sunbird Only → General
QA Contact: sunbird → general
Assignee: nobody → robin.edrenius

Updated

10 years ago
Duplicate of this bug: 425781
Comment on attachment 211484 [details] [diff] [review]
add a check for ondragexit

Since we are nearing the last branch release, I think we should go ahead and take this.

I've tested this and it works like a charm. I also tested ondragdrop, but for some reason it doesn't seem to work.

We should add a comment thought that this should be removed once the upstream bug is fixed.

I'll take care during checkin.
Attachment #211484 - Flags: review+
Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED
Status: NEW → RESOLVED
Last Resolved: 9 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → 0.9
You need to log in before you can comment on or make changes to this bug.