Closed
Bug 326792
Opened 19 years ago
Closed 16 years ago
'Next' button doesn't change to active when dragging an URL into text field
Categories
(Calendar :: General, defect)
Calendar
General
Tracking
(Not tracked)
RESOLVED
FIXED
0.9
People
(Reporter: cz, Assigned: robin.edrenius)
References
Details
Attachments
(1 file)
(deleted),
patch
|
Fallen
:
review+
jminta
:
first-review-
|
Details | Diff | Splinter Review |
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•19 years ago
|
||
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•19 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•19 years ago
|
Comment 3•19 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•18 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-
Updated•17 years ago
|
Assignee: robin.edrenius → nobody
Status: ASSIGNED → NEW
Component: Sunbird Only → General
QA Contact: sunbird → general
Updated•17 years ago
|
Assignee: nobody → robin.edrenius
Comment 6•16 years ago
|
||
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+
Comment 7•16 years ago
|
||
Checked in on HEAD and MOZILLA_1_8_BRANCH
-> FIXED
Status: NEW → RESOLVED
Closed: 16 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.
Description
•